tyvm:) On Mon, Mar 14, 2016 at 7:58 PM, Jonathon Pendlum < jonathon.pend...@ettus.com> wrote:
> Hi Nikos, > > 1) The Fosphor RFNoC block does not compute a FFT. It does the averaging > and persistence. > 2) For RFNoC flowgraphs, you want to use a RFNoC Radio block so you do not > transition out of the FPGA processing domain as would happen the USRP > source / sink block. We want to stay in the FPGA processing domain for as > long as possible before transitioning to host processing. > The QT display is used to display Fosphor's output on your PC / laptop's > monitor. Everything related to actually displaying graphics is done on the > host, but the computation to generate those graphics is done on the FPGA. > > > > Jonathon > > On Fri, Mar 11, 2016 at 7:15 PM, Nikos Balkanas <nbalka...@gmail.com> > wrote: > >> Correction: Spectrum shows fine. Just had to enlarge the panel:) >> >> On Sat, Mar 12, 2016 at 1:26 AM, Nikos Balkanas <nbalka...@gmail.com> >> wrote: >> >>> Thanks Jonathan, >>> >>> That helps a lot. I still don't get a spectrum, but I get a nice fosphor >>> panel and no timeout errors. A couple of questions: >>> >>> 1) You seem to be using 2 ffts: RFNoC FFT and RFNoC Fosphor. You can >>> only do 1 FFT. What's the difference between those 2? >>> 2) You start with an RFNoC Radio instead of a USRP source. Does that >>> mean that the flow is intended to run from the FPGA? What is the meaning of >>> the QT display in such a scenario? >>> >>> BR, >>> Nikos >>> >>> >>> On Sat, Mar 12, 2016 at 12:52 AM, Jonathon Pendlum < >>> jonathon.pend...@ettus.com> wrote: >>> >>>> Hi Nikos, >>>> >>>> Have you tried running the example fosphor flowgraph in >>>> gr-ettus/examples/rfnoc? >>>> >>>> >>>> >>>> Jonathon >>>> >>>> On Fri, Mar 11, 2016 at 2:14 PM, Nikos Balkanas <nbalka...@gmail.com> >>>> wrote: >>>> >>>>> Upon closer inspection I do get a few runtime errors: >>>>> >>>>> timeout on chan 0 >>>>> >>>>> Looks like smt is amiss in my flow. Any ideas about that? >>>>> >>>>> TIA >>>>> Nikos >>>>> >>>>> On Sat, Mar 12, 2016 at 12:07 AM, Nikos Balkanas <nbalka...@gmail.com> >>>>> wrote: >>>>> >>>>>> Tyvm Jason, >>>>>> >>>>>> That did it. I don't actually need to set the X300's addr and type to >>>>>> anything. It defaults to the first one it finds, and I got only 1 ;-) >>>>>> I got the top block running without any errors. Not much of a fosphor >>>>>> display, like I'm used to, but I'm happy i didn't get any errors:) >>>>>> >>>>>> BR, >>>>>> Nikos >>>>>> >>>>>> On Fri, Mar 11, 2016 at 5:13 PM, Jason Matusiak < >>>>>> ja...@gardettoengineering.com> wrote: >>>>>> >>>>>>> (accidentally sent original response to the wrong mailing list. >>>>>>> sorry) >>>>>>> >>>>>>> >>>>>>> Nikos, All RFNoC scripts require a Device3 block. If you look under >>>>>>> UHD>RFNoC in GRC you will see Device3. Just add that to your design (no >>>>>>> connections needed) and if you are using an X310, set your device >>>>>>> argument >>>>>>> to "addr=xx.yy.zz.aa" and device address to "type=x300". >>>>>>> >>>>>>> Make sense? >>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>> >>>> >>> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
