Ah, I see - thanks for the insights, Marcus. Unfortunately, we’re playing a somewhat precarious game near the edge of the STFT time-bandwidth product limit. On the one hand, we need a long enough FFT to minimize bleeding between channels. On the other, we also need to keep most of the FFT packets in any given ~1ms time window in order to maintain sufficient statistical strength in the downstream processing, which filters out short pulses that may sometimes be present in the band.
Unfortunately, as a result the FPGA will probably not be very useful to us with “Keep 1 in N.” However, we might be able to get away with buffering a large number of FFT windows into 1 ms blocks, and then do the vector sum on the host. Is there a way to “trigger” bursts like this? I suppose we could just allow the buffer overflow to do the rate limiting for us :-) Dan From: Marcus D. Leech <[email protected]> Sent: Friday, February 11, 2022 9:33 AM To: [email protected] Subject: [USRP-users] Re: RFNoC and time vs frequency averaging 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 mag2 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 (mag2 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]
