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
