Hi Daniel, Here a few notes regarding your questions:
> Is it possible in the rfnoc framework? Can I change the ce clock of my OOT > block to a higher clock than 266e6 ? As I mentioned in my previous response, it is technically possible but would require larger modifications on the FPGA side on your part, so if you are not that familiar with FPGA development I would recommend against it. While changing the clock rate of the CE clock could be done in theory, the FPGA code has only been validated to work when running with the default clock rate of 266MHz, which is already one of the highest clock rates used in the current FPGA implementation. Increasing this rate further will most likely lead to timing failures when you try to rebuild the bitfile, which would then require manual optimization to meet the tighter timing. I’m assuming you would want to double it, which I think would be extremely hard to do with the current implementation, so I would strongly advise against this. You would most likely have to write a new optimized ddc implementation that can run at 500MHz, or you would have to try to parallelize the implementation to enable it to process multiple samples per clock cycle which is also not trivial, especially since the current DDC implementation has not been updated in quite some time. > can i change the DDC clock to something lower than 266.66MHz (for sample rate > smaller than 100M) Not sure I understand what you mean here. Decreasing the CE clock would mean that the current DDC block implementation could only support even lower input sampling rates(for 100MHZ this would be somewhere in the range of \~90MSps), so I do not see how this would help your use case of processing the full 500 MSps of input data coming from a single radio channel. > or I must upload the samples to the host ? This would be the easiest option, as it does not require any FPGA modifications, although the downside is that you would need a host setup that can handle receiving the data at these high rates: 491\.52MSps \* 32bit per sample => \~15.72Gbps, requiring a 100GbE connection or equivalent. This can be a challenge for a lot of non-optimized host setups. Sorry I couldn’t be of more help.\ \ Regards,\ Niels --- Daniel Ozer wrote: > Thank you for the detailed response. > In the end, I want to take all 491.52e6 band (from 1 Rx) and split it into > smaller bands. > Is it possible in the rfnoc framework? Can I change the ce clock of my OOT > block to a higher clock than 266e6 ? > or I must upload the samples to the host ? > > * can i change the DDC clock to something lower than 266.66MHz (for sample > rate smaller than 100M) > thanks in advance > > בתאריך יום ד׳, 14 בינו׳ 2026 ב-18:35 מאת niels.steffen.garibaldi--- via > USRP-users <[email protected]>: > > > Hi Daniel, > > > > The short answer is that the current DDC/DUC implementations will not work > > for Sampling rates above 250MHz. > > > > The long Answer: > > The current implementation of the DDC/DUC RFNoC blocks only supports a > > single sample per clock cycle processing of data. > > > > Internally the DDC/DUC blocks use the faster CE(Compute Engine) clocks to > > do the Down-/Upconverting, which on your X440 device is running at > > 266\.66MHz <https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#X440>. > > > > Therefore the highest sampling rates supported by the DDC/DUC blocks is > > 250MHz, which corresponds to the 200MHz BW variants of the provided > > bitfiles. > > > > If the radio provides samples at a higher rate, they will still reach the > > DDC block but the internal serialization buffers will fill up quickly as > > the block can not process incoming samples fast enough. This will lead to > > an overflow, which might be related to why your rfnoc session times out. > > > > This is the also the main reason why only the “\*_200_rfnoc_image_core.yml” > > variants have the DDC/DUC blocks included. > > > > You can still capture samples at a faster sampling rate, but you will have > > to stream them to your host first and then do the downconversion there. > > Be aware that this requires a fast connection between USRP and Host, which > > can be challenging in some setups. > > > > Another thing you could try is to reduce the MCR closer to your target > > sampling rate. The x440 supports a wider variety of flexible sampling rates > > than the other USRPs, so if you only care about the downsampled waveform, > > you could just try to get close to your desired sampling rate that way. See > > the > > appendix of this document for a list of supported sampling rates of the x440 > > <https://kb.ettus.com/About_Sampling_Rates_and_Master_Clock_Rates_for_the_USRP_X440#Appendix> > > . > > > > If you still require this feature, you will either have to update the > > implementation yourself and make the DDC/DUC multisample capable, or you > > could try and contact Ettus/NI/Emerson support and put in a feature > > request. Depending on your business case the implementation might be > > prioritized and updated in a future release. > > > > Regards, > > Niels > > > > --- > > > > USRP-users mailing list -- [email protected] > > To unsubscribe send an email to [email protected]
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
