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 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
