Hi Ramazan, The VectorIIR RFNoC block implements a vector of low pass single-pole IIR filters. The idea is that the spectral content of each FFT bin in the time direction is low frequency enough that you can low pass filter (VectorIIR) and decimate (Keep one in N) without significant loss of information.
Jonathon On Tue, Feb 19, 2019 at 11:30 PM Jason Matusiak < ja...@gardettoengineering.com> wrote: > Ramazan, > > The timeout channel 0 error is using a timeout that RFNoC is throwing. > There is a timeout built in that can be ignored if you are purposely > dropping a bunch of samples in the RFNoC domain (which I do in a few > flowgraphs). If you dig through the mailing list, someone pointed to where > in the code this gets printed; they comment it out so they don't have to > see it. It is pretty annoying to me when I am trying to drop samples on > purpose, but I haven't commented it out since I want to see it if I wasn't > trying to drop samples. My money is on your keep-1-in-n tripping this up. > > > > > > ------------------------------ > *From:* USRP-users <usrp-users-boun...@lists.ettus.com> on behalf of > Ramazan Çetin via USRP-users <usrp-users@lists.ettus.com> > *Sent:* Tuesday, February 19, 2019 7:11 AM > *To:* Jonathon Pendlum; usrp-users@lists.ettus.com > *Subject:* Re: [USRP-users] E310 RFNoC FFT Overrun Issue > > > Hi Jonathon, > > Thanks you for your suggestions. I have achieved getting 60 MHz spectrum > samples to file on ARM processor using; > > RFNoC: Radio -> RFNoC: FFT -> RFNoC: Vector IIR -> RFNoC: Keep 1 in N -> > File Sink > > It just getting overflows after 4-5 seconds such as "*overrun on chan 0*". > Is this because of *RFNoC* side or *processor* side ? > > Also, Keep 1 in B block works as using packets not samples this is also > perfect for me. I will not lose FFT bins. > > But i can not much understand Vector IIR part. Why is it used and good for > FFT outputs? Is it for averaging results ? > > Thank you for your time. Best regards. > > Ramazan > On 11.02.2019 08:09, Jonathon Pendlum wrote: > > Hi Ramazan, > > I would suggest first testing with a signal generated with GNU Radio. For > example, use a Fast Noise Source + Low Pass Filter to crudely simulate > receiving a wide band signal. See what it looks like without running it > through RFNoC. Then replace the RFNoC radio block with those blocks and > look at the result. > > You should also consider using the ZeroMQ blocks to forward data over > Ethernet to a host PC to view your data in real time. Look at the gr-ettus > example flowgraphs rfnoc_fft_network_usrp (runs on E310) and > rfnoc_fft_network_host (runs on host PC). > > One guess I can make is try increasing the FFT RFNoC block gain. By > default, it is set to a very conservative value, so try changing it to 21. > That gain value sets the Xilinx's FFT IP core scaling schedule, which you > can read about here: > https://www.xilinx.com/support/documentation/ip_documentation/xfft/v9_0/pg109-xfft.pdf > (see SCALE_SCH on page 15, the core uses Radix-4). You can also try > adjusting it with a slider in real time. Note that it may behave a bit odd > as it is not a linear mapping due to the scaling schedule format. > > The overflows are due to either the ARM processors cannot keep up with the > processing load or the SD card write speed is too slow. Try increasing N in > Keep One in N. > > Jonathon > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
