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
