Hello. Please tell me how things are with my question? Perhaps I need some additional information?
вт, 14 сент. 2021 г. в 22:30, Marcus D. Leech <patchvonbr...@gmail.com>: > On 2021-09-14 10:24 a.m., Rob Kossler wrote: > > Hi Ivan, > If your issues are still the following: streaming works fine for FFT > length 256, but causes streaming errors at FFT lengths 512 and above, the > issue is very likely related to the packet length that the FFT block > produces. > > The stock RFNoC FFT block from Ettus asserts TLAST on the final FFT > sample, which makes the packet length equal to the FFT length. For a 512 > point FFT, this means that the number of bytes in a packet is > 2048+header_bytes. This is a problem if the interface MTU is less than > that (often at 1500). So, the answer is to figure out how to get the > interface MTU set to a larger value. If that is not possible, then the > answer is to modify the FFT block so that the packet length is not > dependent on the FFT size. For example, the FFT block could assert TLAST > every 256 samples, independent of the actual FFT length. There are old > posts about this if you search the archive. > Rob > > Thanks, Rob. > > But we've already covered that territory--turns out there IS a bug in > recent UHD with FFT and FIR (and other vector functions I think) lengths > > 256, and a bug > has been raised. > > > > On Mon, Sep 13, 2021 at 5:30 PM Marcus D. Leech <patchvonbr...@gmail.com> > wrote: > >> On 2021-09-13 2:29 p.m., Ivan Zahartchuk wrote: >> >> Tell me how to create a yaml file for such a graph correctly? I tried like >> this but I get errors. I have not found such examples. >> >> >> Please copy user-users on these e-mails. Others may have better insights >> than myself on these things, and bringing in the wider >> community is always a good idea. >> >> The phrase "but I get errors" isn't terribly useful unless those errors >> are included in the problem report. I MAY or MAY NOT be able >> to help, since I'm not an RFNOC user or developer. But without those >> errors available to the people you're asking for help, >> it's pretty tough to do ANYTHING. >> >> >> ср, 8 сент. 2021 г. в 02:13, Marcus D. Leech <patchvonbr...@gmail.com>: >> >>> On 2021-09-07 5:55 p.m., Ivan Zahartchuk wrote: >>> >>> I am setting 256 points FFT with the following parameters:fft_amplitude = >>> uhd.libpyuhd.rfnoc.fft_magnitude.MAGNITUDE_SQUAREDfft_direction = >>> uhd.libpyuhd.rfnoc.fft_direction.FORWARDfft_shift = >>> uhd.libpyuhd.rfnoc.fft_shift.NORMALAfter that I do abs and display the >>> data. Tell me how to do it better? And do I need to set a different type >>> for the array which is passed to the recv function when setting Mag ** 2? >>> >>> Actually, there IS a logpwr block in RFNOC. I don't know exactly what >>> scaling strategy it uses. >>> >>> If I wanted to get power estimates out of an RFNOC FFT, I'd have: >>> >>> FFT(with MAG2)--->MOVING_AVG--->KEEP-ONE-IN-N all inside RFNOC, and >>> then scale to my hearts content at leisurely rates on the host. >>> >>> >>> >>> ср, 8 сент. 2021 г. в 00:43, Marcus D. Leech <patchvonbr...@gmail.com>: >>> >>>> On 2021-09-07 4:17 p.m., Ivan Zahartchuk wrote: >>>> >>>> Hello. There is any information on my question. I also noticed that if you >>>> take the data after the FFT, then the sensitivity drops very much. I see a >>>> -30 dBm signal but -60 dBm is no longer displayed. >>>> >>>> How are you scaling and displaying your FFT output? What options do >>>> you have set on your FFT? DO you have it using Mag**2, how do you scale it >>>> after that? >>>> >>>> >>>> >>>> сб, 4 сент. 2021 г. в 00:04, Ivan Zahartchuk <adray0...@gmail.com>: >>>> >>>>> Here is my script. I am trying to read different amounts of data from DDC >>>>> and from FFT.Are there any new statements on my question? >>>>> >>>>> >>>>> чт, 2 сент. 2021 г. в 10:06, Jonathon Pendlum < >>>>> jonathon.pend...@ettus.com>: >>>>> >>>>>> Great, thanks. Can you also share your latest python script? >>>>>> >>>>>> Jonathon >>>>>> >>>>>> On Wed, Sep 1, 2021 at 6:37 PM Ivan Zahartchuk <adray0...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Yes, I can try it but next week. But I still wanted to do FFT on FPGA. >>>>>>> And one more question. Is it possible to create two streamers and read >>>>>>> 256 samples one at a time and another 8192 for example? I want to do >>>>>>> FFT on one channel and start a stream with DDC for demodulation on the >>>>>>> other. What is possible? >>>>>>> >>>>>>> >>>>>>> ср, 1 сент. 2021 г. в 21:09, Jonathon Pendlum < >>>>>>> jonathon.pend...@ettus.com>: >>>>>>> >>>>>>>> Hi Ivan, >>>>>>>> >>>>>>>> Can you try running your script with the SPP set to 512 and without >>>>>>>> the FFT block, i.e. Radio -> Rx Streamer? This may be a general issue >>>>>>>> with >>>>>>>> SPP unrelated to the FFT. I'm getting the same "Bad CHDR packet" error >>>>>>>> on a >>>>>>>> different device with the FIR filter block, but it goes away when I >>>>>>>> remove >>>>>>>> the block. >>>>>>>> >>>>>>>> Jonathon >>>>>>>> >>>>>>>> On Mon, Aug 30, 2021 at 3:46 PM Marcus D. Leech < >>>>>>>> patchvonbr...@gmail.com> wrote: >>>>>>>> >>>>>>>>> On 2021-08-30 2:30 p.m., Ivan Zahartchuk wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks. Still trying to work this out. In UHD 4, the interface to >>>>>>>>> the FPGA changed from a straightforward DMA implementation--done by >>>>>>>>> ADI for >>>>>>>>> their IIO subsystem, to a driver that makes the FPGA/Radio >>>>>>>>> "look" like a network device with an MTU of 9000. >>>>>>>>> >>>>>>>>> With an MTU that large, you should have no trouble with 512-bin >>>>>>>>> FFTs. But clearly, you are. >>>>>>>>> >>>>>>>>> The "int0" network interface exists only while there's a session >>>>>>>>> with the radio, so it won't show up in "ifconfig" unless there's a >>>>>>>>> session >>>>>>>>> active, >>>>>>>>> and it indeed has an MTU of 9000. So MTU isn't your problem. >>>>>>>>> It's something else, and I'm not sure what at the moment. >>>>>>>>> >>>>>>>>> >>>>>>>>> пн, 30 авг. 2021 г. в 15:08, Marcus D. Leech < >>>>>>>>> patchvonbr...@gmail.com>: >>>>>>>>> >>>>>>>>>> On 2021-08-29 7:17 a.m., Ivan Zahartchuk wrote: >>>>>>>>>> >>>>>>>>>> Thanks a lot. Here is my output with uhd_usrp_probe and my code: >>>>>>>>>> >>>>>>>>>> Could you share with us the output of: >>>>>>>>>> >>>>>>>>>> ip link >>>>>>>>>> >>>>>>>>>> or ifconfig >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> сб, 28 авг. 2021 г. в 20:19, Marcus D. Leech < >>>>>>>>>> patchvonbr...@gmail.com>: >>>>>>>>>> >>>>>>>>>>> On 2021-08-28 10:49 a.m., Ivan Zahartchuk wrote: >>>>>>>>>>> >>>>>>>>>>> Tell me who I can turn to for help or how can I solve the problem >>>>>>>>>>> with the fact that I cannot set the number of FFT points> 256. I >>>>>>>>>>> apologize for my persistence, but this is critical for me. Thank >>>>>>>>>>> you for understanding. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ivan, I've been poking around all morning try to find where >>>>>>>>>>> there may be a limit. I can't find it. I'm hampered by not being >>>>>>>>>>> an RFNOC >>>>>>>>>>> expert. >>>>>>>>>>> >>>>>>>>>>> I have a query in to Ettus R&D, but it being the weekend, I >>>>>>>>>>> don't expect any kind of answer until Monday. >>>>>>>>>>> >>>>>>>>>>> Could you share your Python code, and the output of >>>>>>>>>>> uhd_usrp_probe on your E310? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>> >>> >> _______________________________________________ >> USRP-users mailing list -- usrp-users@lists.ettus.com >> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >> > >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com