On 2022-02-11 10:38, Kuester, Dan (Fed) via USRP-users wrote:
Hi everyone,
I’m hoping for some advice on using RFNoC for a spectrum analysis
application (I have another hardware clocking question that I’m going
to ask separately).
Context: we need to continuously stream channel power in a bank of 8
contiguous 10 MHz bands on short (a few microseconds) time scales. To
manage the initial deluge of IQ, I’d like to use an FPGA to perform a
512-point FFT and then reduce the volume of data by summing up mag^2
across frequency to give channel power. The resulting stream of 8
channel power readings every few microseconds is then pretty
manageable for transport and processing on the host.
After looking at the RFNoC block list, the (wishful thinking? :-))
implementation in my head looks like this:
(Radio) → Window → FFT (mag^2 output) → Vector IIR to sum across
frequency bins → Keep 1 in N → (Stream to host)
Some questions have come up on this:
1. Does the Vector IIR at the output of an FFT operate across time or
frequency? For “Keep 1 in N,” there’s a clear flag to determine
whether the operation is applied by sample or by packet, but I
don’t see anything about which of these “Moving Average” “Vector
IIR” operate on.
2. Are there any obvious fixed-point traps in doing this?
3. Are there any other pitfalls that I’m missing here?
Thanks in advance for any ideas!
The vector IIR operates across time, so it cannot be used to reduce the
effective frequency resolution of the FFT, as you suggest.
Why not simply use the smallest FFT possible in the FPGA, with mag**2
outputs, then vector IIR that, then keep-one-in-N, then do the
resolution reduction on the host at a now much-more-modest rate?
For example, a 64-point FFT with 100MHz input rate gives you 1.56e6 FFT
outputs/second. IIR and drop this to perhaps 1/8 of that, and even
an rPi4 should be able to do the vector sum operation to reduce
effective resolution.
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]