Thank you for your response and for confirming the general approach to the
configuration. I have a couple more questions related to RFNoC, particularly
about buffer size in SEP (Stream Endpoints) and IP address settings.
1. Buffer Size in SEP:
I’m having some difficulty understanding the correct setting for buffer size in
SEP. I’ve found conflicting information:
On page: https://kb.ettus.com/RFNoC_Frequently_Asked_Questions
it says: "Set to 0 if you don't need to send data to that SEP."
Meanwhile, this other page:
https://kb.ettus.com/Getting_Started_with_RFNoC_in_UHD_4.0
states: "Alternatively, if we know that a particular SEP only sends data from
the USRP to the computer, then we won't need the ingress data buffer and we can
set buff-size to 0, thus saving FPGA resources."
Could you clarify which is correct? And based on the following SEP
configuration, have I set the buffer sizes correctly for my use case?
Here’s my current SEP setup:
# General parameters
# -----------------------------------------
...
chdr_width: 64 # Bit width of the CHDR bus for this image
device: 'x310'
default_target: 'X310_XG'
# A list of all stream endpoints in design
# ----------------------------------------
stream_endpoints:
ep_s0ddc0: # Stream endpoint name
ctrl: True # Endpoint passes control traffic
data: True # Endpoint passes data traffic
buff_size: 32768 # Ingress buffer size for data
ep_keepn0:
ctrl: True
data: True
buff_size: 0
ep01:
ctrl: True
data: True
buff_size: 0
ep_scanner:
ctrl: True
data: True
buff_size: 32768
ep11:
ctrl: True
data: True
buff_size: 0
...
# Static routing table is:
[DEB] radio0-out_0 (8,0) => ddc00-in_0 (6,0)
[DEB] ddc00-out_0 (6,0) => split0-in_0 (12,0)
[DEB] split0-out_0 (12,0) => keepn0-in_0 (13,0)
[DEB] keepn0-out_0 (13,0) => ep_keepn0-in0 (2,0)
[DEB] split0-out_1 (12,1) => s0ddc0-in_0 (14,0)
[DEB] s0ddc0-out_0 (14,0) => ep_s0ddc0-in0 (1,0)
[DEB] radio0-out_0 (8,0) => ddc01-in_0 (7,0)
[DEB] ddc01-out_0 (7,0) => ep01-in0 (3,0)
[DEB] radio1-out_0 (11,0) => ddc10-in_0 (9,0)
[DEB] ddc10-out_0 (9,0) => windw0-in_0 (15,0)
[DEB] windw0-out_0 (15,0) => fft0-in_0 (16,0)
[DEB] fft0-out_0 (16,0) => logpwr0-in_0 (17,0)
[DEB] logpwr0-out_0 (17,0) => ep_scanner-in0 (4,0)
[DEB] radio1-out_0 (11,0) => ddc11-in_0 (10,0)
[DEB] ddc11-out_0 (10,0) => ep11-in0 (5,0)
2. IP Address Configuration:
I initially set up the X310 with the HG image and configured the IP address to
something like 192.168.50.2. Later, I switched to the XG image, which uses the
default IPs of ...30.2 and ...40.2. When I load my custom image, will the IP
addresses remain consistent? I'm concerned about "bricking" the device,
especially after reading issues like this one:
https://github.com/EttusResearch/uhd/issues/550 . I want to make sure I avoid
any potential pitfalls.
Your advice would be greatly appreciated, as I cannot afford any setbacks with
this device.
Thank you for your continued support.
Best regards,
Olo.
On Tuesday, August 27th, 2024 at 9:47, Martin Braun <martin.br...@ettus.com>
wrote:
> On Mon, Aug 26, 2024 at 7:14 PM Olo via USRP-users
> <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?
>
> I didn't build and test it, but if it manages to squeeze in all the IP, I see
> no general issues.
>
> Note that after the split block, you need to collect all the data from both
> outputs, meaning you need a full streaming setup. Make sure the total data
> doesn't exceed your link capabilities (i.e., that you are not oversubscribing
> your 10 GbE connection, and that your receiving computer is fast enough).
>
>> 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?
>
> Same answer: If it fits, you're good.
>
> --M
>
>> 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> 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
