Hi Daniel, It sounds like what you may need is a channelizer of some kind. For example, an 8-point FFT block would filter your input signal into 8 equal bandwidth streams (while decimating by 8). I think a more general channelizer might be what you need though. I just did a quick search and noticed this <https://github.com/EttusResearch/rfnoc-pfb-channelizer>although it is 8 years old. Rob
On Thu, Jan 29, 2026 at 7:28 AM niels.steffen.garibaldi--- via USRP-users < [email protected]> wrote: > 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] >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
