usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsAssistance with RFNoC and TwinRX Configuration in Custom FPGA Image
Hello,
I am currently working on a custom FPGA image that utilizes RFNoC blocks provided by Ettus through the UHD repository. Specifically, I am using blocks such as split, window, fft, and logpwr in my design.
My goal is to achieve the following:
- First TwinRX (radio0): Use one channel to display every n-th PSD, while simultaneously recording a narrowband channel within the displayed spectrum (using split and ddc).
- Second TwinRX (radio1): Rapidly sweep a large bandwidth and display the PSD, also utilizing the window, fft, and logpwr blocks.
I would greatly appreciate your feedback on the following points:
- Validation of Initial Design: I have attached my initial attempt at creating this FPGA image. Could you please review it and let me know if this approach is correct?
- Achieving Specific PSD Size: Is it possible to achieve a PSD size of, for example, 8192 using the window, fft, and logpwr blocks? If so, could you advise on the necessary steps to accomplish this?
- TwinRX Channel Configuration: Is it feasible to use the second channel on the second TwinRX to receive on a static frequency while the first channel sweeps, and vice versa, can the second channel on the first TwinRX sweep a portion of the spectrum while the first channel remains on a static frequency?
Your guidance on these questions would be extremely valuable, as it is critical to the success of my project.
Thank you in advance for your support. I look forward to your response.
Best regards,
Olo.
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
On Mon, Aug 26, 2024 at 7:41 AM Olo via USRP-users <
usrp-users@lists.ettus.com> wrote:
Hello,
I am currently working on a custom FPGA image that utilizes RFNoC blocks
provided by Ettus through the UHD repository. Specifically, I am using
blocks such as split, window, fft, and logpwr in my design.
My goal is to achieve the following:
1. *First TwinRX (radio0):* Use one channel to display every n-th PSD,
while simultaneously recording a narrowband channel within the displayed
spectrum (using split and ddc).
2. *Second TwinRX (radio1):* Rapidly sweep a large bandwidth and
display the PSD, also utilizing the window, fft, and logpwr blocks.
I would greatly appreciate your feedback on the following points:
1. *Validation of Initial Design:* I have attached my initial attempt
at creating this FPGA image. Could you please review it and let me know if
this approach is correct?
2. *Achieving Specific PSD Size:* Is it possible to achieve a PSD size
of, for example, 8192 using the window, fft, and logpwr blocks? If so,
could you advise on the necessary steps to accomplish this?
3. *TwinRX Channel Configuration:* Is it feasible to use the second
channel on the second TwinRX to receive on a static frequency while the
first channel sweeps, and vice versa, can the second channel on the first
TwinRX sweep a portion of the spectrum while the first channel remains on a
static frequency?
Your guidance on these questions would be extremely valuable, as it is
critical to the success of my project.
Thank you in advance for your support. I look forward to your response.
Best regards,
Olo.
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
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
On Mon, Aug 26, 2024 at 7:41 AM Olo via USRP-users
usrp-users@lists.ettus.com wrote:
Hello,
I am currently working on a custom FPGA image that utilizes RFNoC
blocks provided by Ettus through the UHD repository. Specifically,
I am using blocks such as |split|, |window|, |fft|, and |logpwr|
in my design.
My goal is to achieve the following:
1. *First TwinRX (radio0):* Use one channel to display every n-th
PSD, while simultaneously recording a narrowband channel
within the displayed spectrum (using |split| and |ddc|).
2. *Second TwinRX (radio1):* Rapidly sweep a large bandwidth and
display the PSD, also utilizing the |window|, |fft|, and
|logpwr| blocks.
I would greatly appreciate your feedback on the following points:
1. *Validation of Initial Design:* I have attached my initial
attempt at creating this FPGA image. Could you please review
it and let me know if this approach is correct?
2. *Achieving Specific PSD Size:* Is it possible to achieve a PSD
size of, for example, 8192 using the |window|, |fft|, and
|logpwr| blocks? If so, could you advise on the necessary
steps to accomplish this?
3. *TwinRX Channel Configuration:* Is it feasible to use the
second channel on the second TwinRX to receive on a static
frequency while the first channel sweeps, and vice versa, can
the second channel on the first TwinRX sweep a portion of the
spectrum while the first channel remains on a static frequency?
Your guidance on these questions would be extremely valuable, as
it is critical to the success of my project.
Thank you in advance for your support. I look forward to your
response.
Best regards,
Olo.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
On 26/08/2024 07:40, Olo via USRP-users wrote:
- TwinRX Channel Configuration: Is it feasible to use the second
channel on the second TwinRX to receive on a static frequency
while the first channel sweeps, and vice versa, can the second
channel on the first TwinRX sweep a portion of the spectrum while
the first channel remains on a static frequency?
The TwinRX cards have independent LOs on each channel, so, in principle,
each channel can be doing something different,
on different frequencies.
On Mon, Aug 26, 2024 at 10:25 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 26/08/2024 07:40, Olo via USRP-users wrote:
1. *TwinRX Channel Configuration:* Is it feasible to use the second
channel on the second TwinRX to receive on a static frequency while the
first channel sweeps, and vice versa, can the second channel on the first
TwinRX sweep a portion of the spectrum while the first channel remains on a
static frequency?
The TwinRX cards have independent LOs on each channel, so, in principle,
each channel can be doing something different,
on different frequencies.
Note that I don't think this issue ever got resolved:
https://lists.ettus.com/empathy/thread/O3A27BGE4ZO3MXQRTBYYDSXBBUISLHO7
So while it works, changing one channel causes some schmutz on the other
channel during the retune. Timed commands with some type of blank-out
period should be used if you want to get rid of those artifacts.
Also note that large signals on one channel will leak into the other at
baseband, I believe. I think it's just the nature of the 2-channel design
using the single ADC and everything being so close.
Brian
On 26/08/2024 11:08, Brian Padalino wrote:
Also note that large signals on one channel will leak into the other
at baseband, I believe. I think it's just the nature of the 2-channel
design using the single ADC and everything being so close.
The datasheet for the ADC shows ca -88dB cross-talk between the two
channels at a notional 80MHz input.
So a strong (0-5dBm) signal on one channel could conceivably be tweaking
the low-order bit on the other channel.
But lay-out issues on the daughterboard could well make that situation
somewhat worse.
Brian
On Mon, Aug 26, 2024 at 10:24 AM Marcus D. Leech patchvonbraun@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
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 wrote:
On Mon, Aug 26, 2024 at 10:24 AM Marcus D. Leech patchvonbraun@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 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
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?
Olo.
On Monday, August 26th, 2024 at 7:13 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?
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 wrote:
On Mon, Aug 26, 2024 at 10:24 AM Marcus D. Leech patchvonbraun@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 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
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 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 wrote:
On Mon, Aug 26, 2024 at 10:24 AM Marcus D. Leech
patchvonbraun@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 tousrp-users-leave@lists.ettus.com
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 patchvonbraun@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 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 wrote:
On Mon, Aug 26, 2024 at 10:24 AM Marcus D. Leech patchvonbraun@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 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-leave@lists.ettus.com
If you had a polyphase channelizer on the FPGA, that would be an efficient
solution to your problem, but there's no such block as part of UHD itself.
There have been channelizer blocks written in the wild, but that would be
something you'd have to figure out.
--M
On Tue, Aug 27, 2024 at 7:17 AM Olo via USRP-users <
usrp-users@lists.ettus.com> 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?
Olo.
On Monday, August 26th, 2024 at 7:13 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?
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> wrote:
On Mon, Aug 26, 2024 at 10:24 AM Marcus D. Leech patchvonbraun@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-leave@lists.ettus.com
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 patchvonbraun@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-leave@lists.ettus.com
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.
- 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)
- 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.braun@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 patchvonbraun@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 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-leave@lists.ettus.com
On Tue, Aug 27, 2024 at 11:34 AM Olo via USRP-users <
usrp-users@lists.ettus.com> wrote:
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.
- 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."
They're both correct! The difference is where you're sending from. In
general, when we say "send", we mean sending data to the device from the
host. In your second quote, note the additional qualifier: "sends data from
the USRP to the computer", which we generally think of as "receive".
Since you're not intending to do any kind of TX, and you don't even have
separate endpoints for sub-sections of your DSP, you could further drop the
buffer sizes you currently have at non-zero. The only thing that gains you
though is a potential increase of build success when running Vivado, and
you can re-use the BRAMs for other things (which in your design is probably
not relevant).
- 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.
The IP addresses are stored in a separate EEPROM and do not get affected
when you re-flash. The only exception is that the HG and the XG images use
different IP numbers, as laid out in our manual (meaning that when you
switch from HG to XG, you should expect a different IP number on SFP0, but
in both cases, the actual number should be whatever it was that you wrote
into the device).
--M
Hello,
I am looking for a detailed block diagram of an X440 radio... There is very little content available on the web... I am to create a "digital twin of the radio.
Thank you in advance and I look forward to hearing from you soon.
Regards,
AJ
From: Martin Braun martin.braun@ettus.com
Sent: Tuesday, August 27, 2024 3:45 AM
To: Olo olo1618@protonmail.com
Cc: usrp-users usrp-users@lists.ettus.com
Subject: [USRP-users] Re: Assistance with RFNoC and TwinRX Configuration in Custom FPGA Image
Note: This message originated from outside the FIU Faculty/Staff email system.
If you had a polyphase channelizer on the FPGA, that would be an efficient solution to your problem, but there's no such block as part of UHD itself. There have been channelizer blocks written in the wild, but that would be something you'd have to figure out.
--M
On Tue, Aug 27, 2024 at 7:17 AM Olo via USRP-users <usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com> 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?
Olo.
On Monday, August 26th, 2024 at 7:13 PM, Olo via USRP-users <usrp-users@lists.ettus.commailto: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.commailto:usrp-users@lists.ettus.com> wrote:
On Mon, Aug 26, 2024 at 10:24 AM Marcus D. Leech <patchvonbraun@gmail.commailto:patchvonbraun@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 filehttps://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.commailto:usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.commailto:usrp-users-leave@lists.ettus.com
On 03/09/2024 15:57, Arnaldo Sans wrote:
Hello,
I am looking for a detailed block diagram of an X440 radio... There is
very little content available on the web... I am to create a "digital
twin of the radio.
Thank you in advance and I look forward to hearing from you soon.
Regards,
AJ
Most of the "interesting" bits of the X440 are in the RFSOC, which is
linked here:
https://docs.amd.com/r/en-US/pg269-rf-data-converter/Conventions
There's Martin Brauns GRCON talk here:
There's an extensive treatise on selecting sample rates here:
https://kb.ettus.com/About_Sampling_Rates_and_Master_Clock_Rates_for_the_USRP_X440
There's schematics for X4x0 family here:
https://files.ettus.com/schematics/x4x0/
And of course, all the FPGA code is published in the GIT repo that you
get UHD source code from.
From: Martin Braun martin.braun@ettus.com
Sent: Tuesday, August 27, 2024 3:45 AM
To: Olo olo1618@protonmail.com
Cc: usrp-users usrp-users@lists.ettus.com
Subject: [USRP-users] Re: Assistance with RFNoC and TwinRX
Configuration in Custom FPGA Image
Note: This message originated from outside the FIU Faculty/Staff email
system.
If you had a polyphase channelizer on the FPGA, that would be an
efficient solution to your problem, but there's no such block as part
of UHD itself. There have been channelizer blocks written in the wild,
but that would be something you'd have to figure out.
--M
On Tue, Aug 27, 2024 at 7:17 AM Olo via USRP-users
usrp-users@lists.ettus.com 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?
Olo.
On Monday, August 26th, 2024 at 7:13 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?
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> wrote:
On Mon, Aug 26, 2024 at 10:24 AM Marcus D. Leech
<patchvonbraun@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-leave@lists.ettus.com
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
Also this: https://uhd.readthedocs.io/en/latest/page_usrp_x4xx.html#x4xx_too
...and of course the entire source code available for your perusal.
Best of luck,
--M
On Tue, Sep 3, 2024 at 11:11 PM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 03/09/2024 15:57, Arnaldo Sans wrote:
Hello,
I am looking for a detailed block diagram of an X440 radio... There is
very little content available on the web... I am to create a "digital twin
of the radio.
Thank you in advance and I look forward to hearing from you soon.
Regards,
AJ
Most of the "interesting" bits of the X440 are in the RFSOC, which is
linked here:
https://docs.amd.com/r/en-US/pg269-rf-data-converter/Conventions
There's Martin Brauns GRCON talk here:
There's an extensive treatise on selecting sample rates here:
https://kb.ettus.com/About_Sampling_Rates_and_Master_Clock_Rates_for_the_USRP_X440
There's schematics for X4x0 family here:
https://files.ettus.com/schematics/x4x0/
And of course, all the FPGA code is published in the GIT repo that you get
UHD source code from.
From: Martin Braun martin.braun@ettus.com martin.braun@ettus.com
Sent: Tuesday, August 27, 2024 3:45 AM
To: Olo olo1618@protonmail.com olo1618@protonmail.com
Cc: usrp-users usrp-users@lists.ettus.com usrp-users@lists.ettus.com
Subject: [USRP-users] Re: Assistance with RFNoC and TwinRX
Configuration in Custom FPGA Image
Note: This message originated from outside the FIU Faculty/Staff email
system.
If you had a polyphase channelizer on the FPGA, that would be an efficient
solution to your problem, but there's no such block as part of UHD itself.
There have been channelizer blocks written in the wild, but that would be
something you'd have to figure out.
--M
On Tue, Aug 27, 2024 at 7:17 AM Olo via USRP-users <
usrp-users@lists.ettus.com> 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?
Olo.
On Monday, August 26th, 2024 at 7:13 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?
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> wrote:
On Mon, Aug 26, 2024 at 10:24 AM Marcus D. Leech patchvonbraun@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-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com