Hey Jason, In regards to your original post, I wonder if the issue is due to the split stream block. Perhaps it has a bubble state and cannot keep up at full rate. Have you tried moving the Keep One in N before the split stream?
Jonathon On Tue, Sep 25, 2018 at 10:07 PM Jason Matusiak via USRP-users < usrp-users@lists.ettus.com> wrote: > OK, now I am really confused. > > Part of my math issue seems to be that I set the "sample rate" in the > RFNoC radio to be my sample_rate because I knew I could ignore due to the > lack of DDC (it would then be set to the master clock rate). > > When I run my flowgraph, I see that the master clock rate is getting set > properly (if I use a bad value, it tells me), but it seems to be running at > the sample rate that is in there (so if I say 25MHz, it will do that > instead of the 56MHz the master clock rate is set to). As far as I know, > this shouldn't happen since I don't have a DDC in my bitfile to allow this > (nor is it in my flowgraph). > > BUT, if I run a benchmark_rate test and set the --rx_rate to be 25e6, it > says that it can't do that and it sets it to be the master clock rate. > > So what gives? Is something happening on the GR side that is doing > something odd with the sample rate? This doesn't add up to me. > > > > --------- Original Message --------- > Subject: general RFNoC timing question > From: "Jason Matusiak" <ja...@gardettoengineering.com> > Date: 9/24/18 2:48 pm > To: "Ettus Mail List" <usrp-users@lists.ettus.com> > > I have a flowgraph I am running on an E310 using all stock RFNoC blocks. > It looks a lot like this: > > > RFNoC:Radio ---> RFNoC: Split Stream ---> RFNoC: FFT ---> RFNoC: Keep 1 in > N ---> RFNoC: Log Power ----> GR: complex to float ---> GR:Raster Sink > | > | > > ---> RFNOC: Keep 1 in N ---> GR: log Power FFT ---> GR: custom block ---> > GR: Raster sink > > So no DDC in the flowgraph. If I run the master_clock_rate at 56MHz, the > sample rate should be the same (I have SPP=512, and that is the size of the > FFT as well). I would then think that the pair of Keep 1 in Ns should > basically divide down the rate by N. So if I have them set to 56e3, that > means I should get a sample rate that averages out to be 1KHz out each of > the two streams to host for a total of 2KHz. I know that the E310 can > stream 10MHz no problem to the ARM, so I am not sure why in this scenario I > get a ton of: > > Ooverrun on chan 0 > Ooverrun on chan 0 > Ooverrun on chan 0 > Ooverrun on chan 0 > Ooverrun on chan 0 > Ooverrun on chan 0 > Ooverrun on chan 0 > > Now why would that be? I have no idea. > > > > I set my downstream sample rate (on the GR host) to be > sample_rate/keep1inN. I bring this up because in the case about > sample_rate is the same as master_clock_rate. If I reduce the sample_rate > to be 40MHz (which gets ignored by the E310 since I don't have a DDC, but > gets used in the down stream sample rate for the raster guis, I can set the > keep1inN up to the max of 65535 and there are no overflows. There are > "timeout on chan 0" errors, but I think that is because RFNoC must be > timing out somewhere du to the throughput being so slow. > > Does this make sense? Does anyone have an idea what I am doing stupidly > wrong? I have a feeling I am violating timing somewhere, but I can't > figure out where.... > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
