SDR as wideband spectrum analyzer

[SarSar100]

Hi everyone. I am curious if anyone one knows any tools that will allow me to use my SDR bladerf2.0 (or any other SDR except hackrf) as wideband scanner 70-6000mHz. I know hackrf has its own hackrf_sweep but I cant find anything similar for bladerf or any other SDR.
I even made a whole python app for windows that basically sweeps LO frequency on bladerf2.0, collects data and visualize it but it takes forever to scan whole band, like 30 seconds which makes it virtually useless. So Im wondering if anyone already found solution for that.

P.S. I posted that app here if anyone is interested https://github.com/MVG1016/Spectrum_analyzer_for_bladerf_2_0_windows

[radiolistener]

The bladeRF 2.0 micro is capable of capturing up to 61.44 MSPS, which gives you approximately 30.72 MHz of usable RF bandwidth per capture (due to Nyquist constraints). Your approach with LO stepping is on the right track.

To maximize sweep performance, one solution would be to develop custom FPGA gateware that operates in ~30 MHz steps. The FPGA could capture and buffer wideband data segments autonomously and push them to the host via USB3 with minimal overhead. The main bottlenecks you'll face are:

- LO retuning and settling time for PLL, which is non-negligible even on the bladeRF 2.0.

- Host interface bandwidth, though USB3.0 should be sufficient for sustained 61.44 MSPS streaming.

- Real-time processing or buffering on the host to handle the high data rate without loss.

Creating a fast, usable wideband scanner requires tight integration between FPGA, FX3 (or equivalent interface controller), and host software. If you want near-real-time scanning across the 70 MHz - 6 GHz range, you’ll need to overlap LO tuning, settling, capture, and transfer steps as much as possible.


You’ll need to implement an LO sweep loop on the FPGA, stepping through the frequency range with increments such that each step captures a ~30 MHz segment (the effective ADC bandwidth). This approach allows full coverage of the desired spectrum.

There’s no need for extremely large FFT - a size of 16k to 64k points per segment is typically sufficient to achieve reasonable frequency resolution. More importantly, you can choose the LO step size carefully so that it’s not an integer multiple of the sampling rate. This helps to suppress image artifacts from adjacent Nyquist zones and mixer-induced mirror frequencies, with post processing.

[SarSar100]

Thanks for the answer,
I was hoping initially to do this in an easier way at a python-level of programming, but it seems that such processing can really only be done at the FPGA level

[tszaboo]

You can use it if you absolutely don't have the budget to buy something like a TinySA. But it's more like a guess -o meter than an instrument. For starters the input is not 50 ohm, sometimes it's not even close. So your readings can be a lot misleading. You cannot set up RWR so it's not comparable to anything.

[SarSar100]

Thanks for the answer,
I wasn't trying to match performane of tinSA with SDR, that would be unrealistic goal, just trying to find a way to bypass that 60mHz bandwidth that most SDR have

[gf]

Thanks for the answer,
I wasn't trying to match performane of tinSA with SDR, that would be unrealistic goal, just trying to find a way to bypass that 60mHz bandwidth that most SDR have

An RTSA has a limited real-time bandwidth, too. To cover a larger span, it must also step the frequency window, but then it is longer real-time. Do you need RT?

[SarSar100]

Yes, i need real time scanning a even somewhat made it in python. The whole problem is the speed of it, if there were any tools to scan the whole band in like 5-7 seconds with SDR that would be cool, but i didnt't find any

[whollender]

You may be able to achieve that kind of timing w/o having to push the whole sweep into the FPGA, but you will still need to put some effort into determining the speed bottlenecks and addressing them.

That will probably require digging pretty deep into the source code stack, but it's doable, and less effort than building a SW stack on top of a custom FPGA sweep engine.

[radiogeek381]

Depending on your ambition and willingness to compromise, many SDRs can do a reasonable job as a "goodnuf" spectrum analyzer.

But you probably won't get a good absolute power measurement out of any of the affordable SDRs. Yes you can calibrate, but the frequency response is not flat across the range of the radio, and may even have intentional dips. For some of these radios you'll have difficulty just getting DC balance and quadrature alignment right, never mind amplitude.

But relative measurements over a reasonably narrow frequency range can be quite good.

I've been using various Ettus USRPs for about 13 years now, ranging from the E100 up to the newest big beasts with two 200 MS/s receivers. In all that time I've *never* found a need to do FPGA design. It just isn't worth the time, and it really isn't the right place to be doing spectral analysis -- useful PSD measurements require more than just an FFT. There's windowing, buffer overlap, and probably larger FFTs than you'd want to do on an FPGA. And then, as has been pointed out, you still have to work through the software API and control.

So what to do? First, figure out just how much spectrum you need to see at one time.

Typically I use a fairly slow sample rate between the radio and the computer. SoDaRadio uses a 625 kHz rate, as I really don't need to see much more than 200 kHz at a time - it was designed as an all-mode transceiver.  Keeping up with rates below about 1.5 MS/s is pretty easy even with old hardware. 

The flip-side of low sample rates is the need to retune if you want to see a wider chunk of spectrum. Most of the affordable SDRs have trouble doing any kind of rapid frequency change in the oscillators between the antenna and the ADC. With delays in the library and driver code and the dynamics of PLL lock, the actual settling time might be hard to verify or even estimate. (I believe that clean oscillators and fast settling times might be in conflict.  I'd rather have a clean LO and tolerate the delay: my N200 has been tuned to the same frequency for more than a week now.)

If you really want to see a wide band all at once, prepare to spend money on both a radio and the computer to eat the data.  I've run some experiments with the high end radios at 100 MS/s but those were mostly streaming to storage. They connect to the host machine via 10 GB fiber and I think I can hear the photons screaming.

So, figure out the sample rate you need, balance it against simultaneous bandwidth and the capability of the host computer. Don't worry a whole lot about real-time response. The better software APIs will forgive you if you get a little behind -- real time response isn't nearly as important as keeping-up.  The USRP run-time code even warns you if you've got insufficient buffer space allocated -- the big buffers make everything a little easier.

So, don't let the FPGA stuff be a barrier. Just ignore the FPGA route and write some code.  Start with python if that's where you're comfortable. If python code can't keep up, you have at least three reasonable options

1. Trim your ambition.
2. Get a faster computer
3. See if a compiled solution (C, C++, whatever) can do the job.

Option 3 isn't all it's cracked up to be. If you do it right, most of the code running in the python app is actually in some library (like Numpy or scipy) that is tuned to Hellengone.  (But I'll confess that I do most of my work in C++ -- I've got a basket of tools (filter builders, overlap-and-save widgets, resamplers, etc.) that I've been carrying around with me for a few years.)

Finally - don't overlook GnuRadio and GnuRadioCompanion.  They're great starting places to experiment. Sometimes that's all you need.

[gf]

The whole problem is the speed of it, if there were any tools to scan the whole band in like 5-7 seconds with SDR that would be cool, but i didnt't find any

The maximum (usable) channel bandwidth of the AD9361 is 56 MHz (at the maximum sample rate). So scanning 70-6000 MHz requires 106 steps. In order to meet the five-second scan time aim, each step can last up to ~47 milliseconds. That actually feels like a lot. Does a single acqusition really take that long? I suggest to add some time.perf_counter() calls to the program to find out which operations consume how much of the time.

What channel bandwidth (step size) and sample rate did you use? Did you scan with too small chunks? If so, try using a sample rate of 61.44 MSa/s and a step size of approximately 56 MHz. [ Btw, to enable seamless stitching of the spectrum, make sure the step size is an integer multiple of sample_rate/fft_size. For example, use 55.998750 MHz (14933 DFT bins) with fft_size=16384. I.e. at each step you would add 14933 of the 16384 DFT bins to the full spectrum. ]

[LeslieGuo]

One caveat with using a 9361-class part as a wideband analyzer: 56 MHz is the maximum instantaneous channel bandwidth (~61.44 MSPS), not the span. To cover a wider range you hop the LO and stitch, so it becomes a swept/sampled system — probability of intercept for short bursts is lower than a true real-time or fast-swept superheterodyne. Also it's zero-IF, so if you don't enable the DC-offset and quadrature tracking calibrations you get a persistent spur sitting at the LO right in the centre of the display, which can look like a real carrier. Fine for bench work once you know it's there.

[radiolistener]

If you need to see the entire 6 GHz bandwidth truly in real time, you could build a set of parallel modules. Each module would consist of an FPGA, a frequency synthesizer, ADC, and a mixer to downconvert a selected 60 MHz segment of the spectrum.

Each module would handle its own 60 MHz slice and output the processed/decimated spectrum in real time at a reasonable data rate. You would need 100 such modules operating in parallel to cover 6 GHz.

Then a larger FPGA-based unit could collect the 100 spectrum fragments, combine them into a single 6 GHz-wide spectrum, and stream the resulting data to the PC.

So the PC could display the entire 6 GHz spectrum in real time, while the heavy parallel processing is done in hardware across many FPGA modules.


However, this approach would be quite expensive and arguably questionable in terms of practicality, since the spectrum resolution on the display would still be relatively low anyway.

It would probably be more efficient to use fewer modules with a narrower effective bandwidth and scan the spectrum step by step, for example in 500 MHz steps. The frequency synthesizers would take some time to retune, so there is still a risk of missing short pulses during the gaps. On the other hand, pulses that short probably would not be visible at the relatively low spectral resolution anyway.

So you could simply find a reasonable trade-off between the bandwidth captured in each step and the number of scanning steps, making sure that you don't lose details that should still be visible in the final spectrum.