Nothing. The timing might be a little different -- if it's tuning effects you're seeing, there's effectively a race condition between tuning and sample collection. Gnuradio will never discard samples off the front unless you use a Skip Head block, which you should probably be doing as evidently you aren't expecting your samples to be tightly synchronized to any particular point in time.
--n On Thu, Jan 15, 2015 at 9:46 AM, Anderson, Douglas J. < dander...@its.bldrdoc.gov> wrote: > Okay, this makes sense. > > What about the version I posted on StackExchange where I *am* using GNU > Radio's scheduler to request the samples? > > What does GNU Radio do when running a constant flowgraph (like uhd_fft) > that it doesn't to when running topblock.run() for each collection, as far > as discarding samples off the front? > > -Doug > ------------------------------ > *From:* Nick Foster [bistrom...@gmail.com] > *Sent:* Thursday, January 15, 2015 10:40 AM > *To:* Anderson, Douglas J. > *Cc:* GNURadio Discussion List > *Subject:* Re: [Discuss-gnuradio] voltage pulse from UHD driver > > In general you cannot use the first few samples of output from an > acquisition. There are a couple of reasons: > > First, if you begin collecting data immediately (rather than using UHD > to schedule a collection at a given time) and you are using a daughterboard > with a downconverter (anything but BasicRX or LFRX), tuning takes some time > and things will be ugly while PLLs settle, etc. > > Second, there are digital halfband and CIC filters in the USRP, and they > are not reset between acquisitions. This means that the first samples will > have some junk left over from the last acquisition. > > Unfortunately, the general answer to what you're trying to do is, don't > do that. > > Best, > Nick > > On Thu, Jan 15, 2015 at 9:26 AM, Anderson, Douglas J. < > dander...@its.bldrdoc.gov> wrote: > >> Hi all, >> >> I've been slowly working to understand/isolate an issue with a strange >> voltage pulse at all freqs and on USRP N210 with 50 Ohm load. >> >> I posted about it on StackExchange here, and there are more details at >> this link: >> http://stackoverflow.com/questions/27968237/semi-consistent-voltage-pulse-from-usrp-when-using-simple-gnu-radio-flowgraph >> >> Since then, I've further isolated it as a UHD issue by completely >> removing the GNU Radio scheduler from the equation and simply using the >> finite_acquisition function on UHD to pull samples directly into Python. >> >> Here is the code I'm using to produce this output >> http://i.imgur.com/c3YWA22.png: >> >> An interesting thing is that when using the UHD driver is used outside >> a flowgraph (uhd.finite_acquisition), I get the strange pulse consistently, >> whereas when used in a flowgraph it was inconsistent (see the StackExchange >> question). >> >> import numpy as np >> import matplotlib.pyplot as plt >> >> FREQ = 800e6 >> RATE = 1e6 >> NSAMPS = 100 >> usrp = uhd.usrp_source(device_addr="", >> stream_args=uhd.stream_args('fc32')) >> usrp.set_center_freq(FREQ) >> usrp.set_samp_rate(RATE) >> >> fig, (freqplot, timeplot) = plt.subplots(2, sharex=True) >> freqplot.set_title("Frequency domain") >> timeplot.set_title("Time domain") >> >> def plot(): >> data = np.array(usrp.finite_acquisition(NSAMPS)) >> shifted_fft = np.fft.fftshift(np.fft.fft(data)) >> dBm = 20*np.log10(np.abs(shifted_fft)) - 30 >> freqplot.plot(dBm) >> timeplot.plot(np.abs(data)) >> >> def run_tb(times=25): >> for _ in range(times): >> plot() >> plt.show(block=False) >> >> >> *Douglas Anderson** | Intern* >> DOC/NTIA/ITS-T | 325 Broadway St., Boulder, CO 80305 | P: 303 497 3582 >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
