The X4_400 image has no decimation inline. That means that the block needs to be able to handle 491.52 or 500 Msps coming into it. That means more than 1 sample per clock being fed into the block. If you don't handle more than 1 sample per clock going into the block, then you will get overflows because the RFNoC framework is translating from N samples per clock down into 1 sample per clock at the clock rate - my guess is it's either 122.88 MHz or 245.76 MHz? - which isn't fast enough to keep up.
I was recently told that the DRAM clock is 250 MHz which makes for a perfect computation engine clock for 491.52 Msps data, but still slightly slow for a 500 Msps stream due to the RFNoC header overhead. tl;dr: Use multiple items per clock in that block to avoid overflow with the X4_400 image. Good luck. Brian On Thu, Apr 20, 2023 at 6:41 PM <jmalo...@umass.edu> wrote: > Hello, > > I am currently working with the X410(X4_400 image) using other the 1Gbe > ethernet only(for now) and an image that uses the following RFNOC graph > > Active connections: > > * 0/Radio#0:0-->0/KeepOneInN#0:0 > > * 0/KeepOneInN#0:0-->RxStreamer#0:0. > > Regardless of any value of N I use(even when the maximum value is used), I > get an overflow error. Though it does appear to effect the number of > samples I recieve: higher values of N gives lower data rates. The data > rates I do get however are far lower then expected despite the overflow > errors. For example, for N = 100, I get around 0.37 KSps, when I would > expect around 4-5 MSps.When I request data using the default images > however, I am able to achieve much higher data rates, at least 10 MSps. Any > tips is very appreciated. > > > Thanks, > > Joe > > > _______________________________________________ > 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
