Central spike on SDRs
Andrew Thornett
That’s a really good observation, Andrew. The central frequency spike (right at the tuned frequency, i.e. DC/0 Hz in the FFT display) is a common feature of most SDRs. It isn’t usually a real signal, but an artifact. The main causes are:
1. I/Q Imbalance
-
SDRs work by digitizing two channels (I and Q, 90° out of phase).
-
If there’s a mismatch in gain, phase, or DC offset between I and Q paths, a residual signal appears at DC.
-
This shows up as a “mirror” spike at the center frequency in waterfall plots.
2. DC Offset Leakage
-
Mixers and ADCs aren’t perfect; some local oscillator (LO) energy or bias leaks through.
-
This produces a constant DC component, which transforms into a narrow spike at the center of the spectrum.
3. Finite ADC Resolution & Imperfections
-
Quantization error, clock jitter, and non-linearities can enhance the central spike.
-
It becomes more obvious at low signal levels when the spike is comparable in size to actual weak signals.
4. Direct Sampling vs. Quadrature Sampling
-
In direct-sampling SDRs (like HF modes on RTL-SDR), the DC spike can be stronger, since there’s less analog front-end filtering to remove LO leakage.
-
In quadrature-sampling SDRs (most common), imbalance between I and Q channels dominates.
5. Software/FFT Artifacts
-
Some SDR software doesn’t fully cancel DC before FFT, making the spike appear more prominent.
-
That’s why many programs offer DC offset correction or I/Q imbalance correction settings.
✅ Practical Fixes:
-
Enable DC offset and I/Q imbalance correction in the SDR software.
-
Shift your tuned frequency slightly off-center, so the DC spike sits between bins and doesn’t mask weak signals.
-
Average or subtract baselines when analyzing spectrograms (especially for radio astronomy).
Great — let’s walk through how you can handle that DC spike and I/Q imbalance in GNU Radio with the SDRplay RSPduo, so your interferometry data at 1420.405 MHz isn’t spoiled.
🔧 Methods in GNU Radio
1. Built-in SDR Source Settings
-
In the SoapySDR or SDRplay source block, check if there are options for:
-
DC offset correction
-
I/Q imbalance correction
(Some drivers expose these, others don’t. SDRplay’s API has support, but not all GNU Radio front-ends expose it.)
2. Block-level Corrections in GNU Radio
a) DC Blocker
-
Use the “DC Blocker” block (under Filters).
-
This is the standard way to remove the constant DC term that becomes the spike at the center frequency.
-
Settings:
-
Length: 1024 (good default; higher = slower adaptation, less distortion).
-
Long-term averaging: Enable if you want a smooth baseline for radio astronomy.
👉 Place it right after your SDR source block, before FFTs, recordings, or correlation.
b) Complex Band-Reject Filter
-
If you want extra suppression, insert a very narrow band-stop filter around DC (±50–200 Hz).
-
That way, any residual LO leakage is not just reduced but nulled.
-
Downside: you lose sensitivity in that narrow band.
c) I/Q Balance
-
GNU Radio has an I/Q Balance block (under Channel Models).
-
It can automatically or manually correct phase/gain mismatch between I and Q streams.
-
For interferometry, it’s worth experimenting with:
-
Adaptive mode = On (auto-learning correction).
-
Alternatively, manually set values if you characterize your RSPduo.
3. Frequency Offset Tuning
-
Another trick: instead of tuning exactly at 1420.405 MHz, offset your LO by, say, +10 kHz.
-
Then, in software, shift the spectrum back down digitally.
-
That way, the DC spike sits at 0 Hz, away from your hydrogen line of interest.
📡 For Your Interferometry Flowgraph
Here’s the recommended block order for clean data:
[SDRplay Source] ↓ [DC Blocker] ↓ [I/Q Balance (adaptive)] ↓ [Frequency XLating FIR Filter] (if you want to re-center the line) ↓ [FFT Sink / File Sink / Correlator]
This ensures the 0 Hz artifact never contaminates your FFTs or correlation output.
Marcus D. Leech
In the B210 (and other Ettus radios), the DC offset is dynamically corrected both by the RFFE chip in the case of the B210, and the small amount of DSP logic in the FPGA.
In *addition*, in Ettus radios, you can use a "tune request" that includes a request for an "offset" LO--the idea being that you can shift the LO outside of your passband, and
have the radio operate more like a "traditional" superhet radio. I use this all the time.
I/Q balance correction is a separate, trickier, subject. In direct-conversion designs, the amplitude and phase balance needs to be exquisitely well balanced in order to have
no in-band images (signals that are "reflected" around DC). No actual hardware is perfect in this regard. So various techniques have been developed over the years
to deal with these "in band" images. Unfortunately, there is no single, "universal" approach to adaptive I/Q correction. Techniques mostly rely on aggregate properties
of the *signals* within the band, and are imperfect.
In the case of interferometry, any active I/Q correction that runs *all the time* stands a very good chance of producing significant unwanted artifacts in your correlator
output--from significant unwanted mutual phase noise, to "false fringes". So I generally turn OFF such methods when I'm doing interferometry. For the B210, my
recollection is that the I/Q correction in the *hardware* is run every time you tune, and takes a fraction of a second, and then any corrections are *fixed* during
the duration of that tuning. This is the optimal way to do this for interferometry--since it won't be making fine amplitude/phase adjustments during your session,
leading to unwanted weirdness int he correlator output.
Further, even with "imperfect" I/Q correction, the resulting image rejection is "good enough" for broadband noise, and even for spectral work, the resulting image rejection
will typically cause images to be very far below your notional noise floor anyway. We aren't demodulating telecom signals here, we're mostly processing broadband noise.