Thank you for your recent response.
However, I noticed that my previous questions about the YAML file configuration
and the use of window and FFT blocks for the scanner (sweep spectrum)
functionality weren't fully addressed. Specifically:
- Could you please review the YAML file I attached in my original email and let
me know if the configuration is correct?
- I plan to use a Window block with a size of 1024 and an FFT block of the same
size for spectrum sweeping. Would this be the right approach given the
limitations you've mentioned?
Your expertise on this matter is crucial, and I would greatly appreciate your
advice to ensure I proceed correctly.
Thank you once again for your continued support. I look forward to your
response.
Olo.
On Tuesday, August 27th, 2024 at 7:23 AM, Marcus D. Leech
<patchvonbr...@gmail.com> wrote:
> On 27/08/2024 01:16, Olo via USRP-users wrote:
>
>> I have an additional question related to my current project involving RFNoC.
>> Specifically, I need to implement as many narrowband channels (DDC) as
>> possible to record various parts of the spectrum as required.
>>
>> I’m wondering if it would be more efficient to handle this through RFNoC or
>> directly on a GPU? Additionally, how many narrowband channels of specific
>> bandwidths could I implement using RFNoC, considering I primarily intend to
>> store (record) the data into memory? I have a clear understanding of the
>> memory and network interface requirements, but I am uncertain about the
>> implications for CPU usage and RAM.
>>
>> Could you provide some guidance on this aspect?
>
> My guess is that you wouldn't be able to create dozens of DDCs, due to
> resource constraints in the FPGA, but adding a handful
> more might not be that big a deal.
>
> But I've never done this, so, just a roughly-educated guess.
>
>> Olo.
>>
>> On Monday, August 26th, 2024 at 7:13 PM, Olo via USRP-users
>> [<usrp-users@lists.ettus.com>](mailto:usrp-users@lists.ettus.com) wrote:
>>
>>> Thank you for your detailed responses to my previous questions. I
>>> appreciate the information provided about the limitations and potential
>>> issues related to FFT size and TwinRX configuration.
>>>
>>> However, I noticed that there was no feedback regarding the YAML file I
>>> attached in my original email. Could you please review it and let me know
>>> if the configuration I've set up is correct?
>>>
>>> Additionally, based on your recommendations, I plan to use a window
>>> function (Window block) with a size of 1024, along with an FFT block of the
>>> same size for the scanner (sweep spectrum) functionality. Would this
>>> approach be correct given the current limitations and your suggestions?
>>>
>>> Your confirmation on these points would be invaluable to ensure that I am
>>> on the right track with my project.
>>>
>>> Thank you once again for your time and assistance. I look forward to your
>>> response.
>>>
>>> Best regards,
>>> Olo.
>>> On Monday, August 26th, 2024 at 18:04, Rob Kossler via USRP-users
>>> [<usrp-users@lists.ettus.com>](mailto:usrp-users@lists.ettus.com) wrote:
>>>
>>>> On Mon, Aug 26, 2024 at 10:24 AM Marcus D. Leech <patchvonbr...@gmail.com>
>>>> wrote:
>>>>
>>>>> On 26/08/2024 10:21, Rob Kossler via USRP-users wrote:
>>>>>
>>>>>> Hi Olo,
>>>>>> On one point regarding an FFT length of 8192, there is likely an issue
>>>>>> with using the Ettus FFT block. In the past (I haven't checked
>>>>>> recently), this block was limited to a maximum FFT size of 1024 because
>>>>>> the entire FFT had to fit in one packet where the maximum packet payload
>>>>>> was about 2000 samples. It is possible to use larger FFTs, but this
>>>>>> requires some custom code that divorces the FFT size from the packet
>>>>>> size.
>>>>>> Rob
>>>>>
>>>>> My understanding is that in recent RFNoC, the limit has been raised to
>>>>> 2048:
>>>>>
>>>>> https://files.ettus.com/manual/classuhd_1_1rfnoc_1_1fft__block__control.html
>>>>
>>>> The [xci
>>>> file](https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/ip/axi_fft/axi_fft.xci)
>>>> still shows a transform length of 1024. Also, I think that the X300 MTU
>>>> size is 10 which implies 2^10=1024 x 64bit is the max payload. This
>>>> implies 2048 32-bit words in the payload. But, because of a few bytes of
>>>> header, it is not possible to use an FFT of length 2048 unless the FFT
>>>> length is divorced from the packet length.
>>>> Rob
>>
>> _______________________________________________
>> 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
