On 01/15/2015 01:11 PM, Anderson, Douglas J. wrote:
Marcus, thank you.. the "optimized for steady state streaming" comment
confirms some suspensions, although I'd love to understand more deeply
why exactly this happens consistently to acquisitions long after a retune.
I think the code snippet I posted to StackExchange might illustrate
the difference I'm seeing a little better. In that example, I did not
use uhd.finite_acquisition, I used a standard flowgraph and
topblock.run().
What if I took that code and tried to just continually plot
acquisitions, almost like a simplified uhd_fft. I would get these
"pulses" whereas you don't see them in uhd_fft. The frontend tune only
happens once, and the only difference I can see about how things are
being handled is that one (uhd_fft) creates one flowgraph and uses a
block to plot the data, whereas in my example I create one flowgraph
and plot the data returned after a toblock.run()
I'm trying to figure out if there's some garbage data/samples created
each time the flowgraph is started that doesn't happen in a constantly
running flowgraph, and your comments somewhat confirm that that is the
case.
Thanks for the info!
-Doug
Could you post that StackExchange code here, please, so that we can
comment on it?
When a flow-graph is run, then stopped, then run again, gr-uhd will have
to go through starting/stopping streaming. Which means you're starting and
stopping the DSP chain in the USRP. That will, necessarily, involve
non-steady-state data. I don't think there's a mode in USRP which basically
says "run DSP steady-state, but don't send me data until I want to
stream samples". Starting streaming/stopping stream also starts/stops the
DSP engine.
------------------------------------------------------------------------
*From:* [email protected]
[[email protected]] on behalf
of Anderson, Douglas J. [[email protected]]
*Sent:* Thursday, January 15, 2015 10:55 AM
*To:* Nick Foster
*Cc:* GNURadio Discussion List
*Subject:* Re: [Discuss-gnuradio] voltage pulse from UHD driver
I don't think it's tuning effects, if I'm understanding that
correctly. You mean that after you retune the USRP, the LO will take
some time to settle?
In the script I posted, that shouldn't be a factor, as the UHD
instance is created and tuned when I import the file in the python
interpreter, and the acquisitions are then run later and without
retuning the USRP.
I might be misunderstanding the issue, like if there is something that
needs to settle each and every time an acquisition is requested
independent of actual frequency tuning.
... but that's the reason for my question: so that I can better
understand the underlying process. Thank you for the details!
-Doug
------------------------------------------------------------------------
*From:* Nick Foster [[email protected]]
*Sent:* Thursday, January 15, 2015 10:49 AM
*To:* Anderson, Douglas J.
*Cc:* GNURadio Discussion List
*Subject:* Re: [Discuss-gnuradio] voltage pulse from UHD driver
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.
<[email protected] <mailto:[email protected]>> 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 [[email protected]
<mailto:[email protected]>]
*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.
<[email protected] <mailto:[email protected]>> 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 <tel:303%20497%203582>
_______________________________________________
Discuss-gnuradio mailing list
[email protected] <mailto:[email protected]>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
