Re: [Discuss-gnuradio] voltage pulse from UHD driver

[Anderson, Douglas J.]

Also for reference, I've attached the plot output by the code in my last post. 
Interestingly, the "pulsed" runs were not always the first ones and not 
contiguous... so there might be 2 "normal" Gaussian lines plotted and then 1 
with the pulse, then 5 good ones, then 1 bad... etc

-Doug

Douglas Anderson | Intern
DOC/NTIA/ITS-T | 325 Broadway St., Boulder, CO 80305 | P: 303 497 3582

________________________________________
From: address@hidden address@hidden on behalf of Anderson, Douglas J. 
address@hidden
Sent: Thursday, January 15, 2015 11:46 AM
To: Marcus D. Leech
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] voltage pulse from UHD driver

I guess in my mind, once the usrp_source device and flowgraph instances were 
created and connected, run() would just be pulling samples through the blocks. 
I read through a presentation on the GNU Radio flowgraph yesterday on 
gnuradio.squarespace.com (can't find the exact link ATM) but failed to clear up 
my understanding of this issue.

Here is the code I was referring to:

from gnuradio import gr, uhd, blocks
import numpy as np
import matplotlib.pyplot as plt

class topblock(gr.top_block):
    def __init__(self, freq=700e6, rate=1e6, nsamps=100):
        gr.top_block.__init__(self)
        self.u = uhd.usrp_source(device_addr="", 
stream_args=uhd.stream_args('fc32'))
        self.u.set_center_freq(freq)
        self.u.set_samp_rate(rate)
        self.head = blocks.head(gr.sizeof_gr_complex, nsamps)
        self.vsink = blocks.vector_sink_c()
        self.connect(self.u, self.head, self.vsink)

tb = topblock()
fig, (freqplot, timeplot) = plt.subplots(2, sharex=True)
freqplot.set_title("Frequency domain")
timeplot.set_title("Time domain")

def plot():
    tb.run()
    data = np.array(tb.vsink.data())
    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))
    tb.head.reset()
    tb.vsink.reset()

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
________________________________
From: Marcus D. Leech address@hidden
Sent: Thursday, January 15, 2015 11:40 AM
To: Anderson, Douglas J.
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] voltage pulse from UHD driver

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: address@hidden<mailto:address@hidden> 
address@hidden<mailto:address@hidden>] on behalf of Anderson, Douglas J. 
address@hidden<mailto:address@hidden>]
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 address@hidden<mailto:address@hidden>]
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. 
<address@hidden<mailto:address@hidden>> 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 address@hidden<mailto:address@hidden>]
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. 
<address@hidden<mailto:address@hidden>> 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
address@hidden<mailto:address@hidden>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio






--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

mpl_pulse.png
Description: mpl_pulse.png