[USRP-users] E310 RFNoC FFT Overrun Issue

Ramazan Çetin ramazan.cetin at gohm.com.tr
Tue Feb 19 07:11:23 EST 2019


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190219/41f4d4d0/attachment.html>


More information about the USRP-users mailing list