[USRP-users] E310 RFNoC FFT Overrun Issue

Jonathon Pendlum jonathon.pendlum at ettus.com
Tue Feb 19 10:50:56 EST 2019


Ramazan,

As Sylvain said, RFNoC Fosphor is another great choice. There already
exists flowgraphs in gr-ettus/examples/rfnoc for the E310 as well (see
rfnoc_fosphor_network_host.grc and rfnoc_fosphor_network_usrp.grc).

Jonathon

On Wed, Feb 20, 2019 at 12:22 AM Sylvain Munaut <246tnt at gmail.com> wrote:

> Just throwing it out there, but have you looked at rfnoc-fosphor ?
>
> I mean capturing and processing large bandwidth spectrum and
> decimating it to low bandwidth data is kind of exactly what it does.
>
> Cheers,
>
>     Sylvain
>
> On Tue, Feb 19, 2019 at 4:19 PM Jonathon Pendlum via USRP-users
> <usrp-users at lists.ettus.com> wrote:
> >
> > 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 <
> jason at 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-bounces at lists.ettus.com> on behalf of
> Ramazan Çetin via USRP-users <usrp-users at lists.ettus.com>
> >> Sent: Tuesday, February 19, 2019 7:11 AM
> >> To: Jonathon Pendlum; usrp-users at 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 at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190220/52b378b2/attachment.html>


More information about the USRP-users mailing list