> but there are diminishing returns True, it's only useful to the dynamic range of that 12-bit ADC. Is there a recommended minimum sample rate for the E310/12? Would this be dictated by the most narrow pre-selection filter?
On Tue, Apr 30, 2019 at 11:50 AM Marcus D. Leech <[email protected]> wrote: > On 04/30/2019 11:43 AM, Luke Whittlesey wrote: > > Just my 2cents, but I think that sometimes running at a higher ADC sample > rate and then digitally filtering may be desirable. I can't say anything > specifically about this example with the E312 because I'm not familiar with > the pre-selection filters and the analog filters in the AD9361, but a > higher sample rate generally allows the analog filter more rolloff before > the ADC aliases that energy back in. > > Yes, and you end up with higher dynamic range as well--but there are > diminishing returns. > > > On Tue, Apr 30, 2019 at 10:53 AM Marcus D. Leech via USRP-users < > [email protected]> wrote: > >> On 04/30/2019 09:15 AM, Jason Matusiak wrote: >> >> I guess I would need a block to count samples if I am going to a null >> sink? Otherwise I am not sure how to guage how many samples have passed. >> >> I was just thinking to look at runtime--for a large enough sample-count, >> the initial startup overhead would be a small fraction of the total >> runtime. >> >> You could use the "benchmark_rate" tool to do this as well. >> >> >> Well, this is probably ignorant of me, but I assumed a higher master >> clock rate would allow me some sort of speed benefit somewhere. I guess I >> can't say what since it has nothing to do with the Linux CPU speed.... >> What is the benefit to running at a slower rate? >> >> No, master_clock_rate has *nothing* to do with CPU speed. It just >> controls the rate that the ADC/DSP/DDC chain runs at in the radio section. >> There's nothing inherently *wrong* with running at a very high >> decimation ratio, it's just that it isn't *necessary*. >> >> >> >> ------------------------------ >> *From:* USRP-users <[email protected]> >> <[email protected]> on behalf of Marcus D. Leech via >> USRP-users <[email protected]> <[email protected]> >> *Sent:* Monday, April 29, 2019 8:33 PM >> *To:* [email protected] >> *Subject:* Re: [USRP-users] E312 wrong sample rate >> >> On 04/29/2019 03:28 PM, Jason Matusiak via USRP-users wrote: >> >> I was debugging a problem with a flowgraph when I realized that I wasn't >> getting the amount of samples I expected passing out of the USRP source >> block. If I set a sample rate too low, it tells me it has to set the >> sample rate to 0.125MSps. Currently I have a single stream from my source >> block, 30MHz clock rate, 500kHz sample rate. >> >> If I run for 20 seconds streaming the data to a file (unbuffered set to >> off) as a complex, I would expect to see 20s * 8B * 500KHz = 80MB of data >> in the file. >> >> Instead, running it empirically (so the numbers will have to be ballpark >> and not exact), I see file size of 116153944. If I make the assumption >> that the sample rate was really 500kHz, that means it ran for 29.03s. This >> is obviously off by 50%. If I assume that 10s of data was really >> collected, that means I had an actual sample rate of 1.451924MSps. >> >> If I run these tests with the minimal 125kHz sample rate, I see things >> off by about double what I would expect. >> >> Moving my sample rate around the 1MSps range seems to work closer to what >> I expect, but of course I can't write files that fast without getting 'O' >> on the screen. Ultimately I need to use two receivers, so I don't believe >> that I can push the clock rate above 30.72MHz. >> >> I am running UHD-3_14 with RFNoC enabled (though I am not using RFNoC in >> this particular flowgraph). What am I missing here? >> >> Have it write to /dev/null, and time how long it takes to gather some >> large number of samples, and go from there. >> If your delivered sample rate is 500ksps, I don't see why you need a >> master clock rate as high as 30Msps, but perhaps you have >> your reasons. >> >> >> _______________________________________________ >> USRP-users mailing list >> [email protected] >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > >
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
