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:
https://events.gnuradio.org/event/21/contributions/392/attachments/123/285/Lo%20and%20behold,%20no%20LO.pdf
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.br...@ettus.com>
*Sent:* Tuesday, August 27, 2024 3:45 AM
*To:* Olo <olo1...@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
<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 tousrp-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
