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 <246...@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@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 < > 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 >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
