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 <patchvonbr...@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: > > > 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> <martin.br...@ettus.com> > *Sent:* Tuesday, August 27, 2024 3:45 AM > *To:* Olo <olo1...@protonmail.com> <olo1...@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 <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 > > > _______________________________________________ > 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
