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

Reply via email to