# Voltage pulse from UHD driver

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

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
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

On 01/15/2015 12:26 PM, Anderson, Douglas J. wrote:

removing the GNU Radio scheduler from the equation and simply using

``````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

You’re grabbing the first 100 samples after you start-up, at 1e6 sps.
That’s 100usec. A good thing to understand is that only part of the
SDR world is entirely in the software domain.

What you’re seeing is the very-much-expected startup transients that
invariably occur with analog hardware. For one thing, there’s no way
that the tuner and mixer will be in a steady-state in the first 100usecs
after startup.

What I would do is grab a few thousand samples, and discard the first
few hundred microseconds after startup.

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. <

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
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. <

On 01/15/2015 12:40 PM, Nick F. wrote:

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.

If the filters were “reset”, what would they be reset to? You have
no way of knowing what is about to arrive from the ADC, so ANY
“pre-load” values you put in the pipeline are necessarily going to be
garbage of one kind or another, so there will always be a startup
transient. It’s as inevitable as the Sun
coming up in the morning, or Starbucks selling you a way-too-expensive
cup of coffee with your name mis-spelled on it

This kind of thing nearly always comes as a shock to folks who might be
encountering real-time signal processing of the analog/physical world.
Ones “mental model” of the ways things work is usually slightly
defective in that it thinks in terms of “steady-state behavior”.

Similar things can be seen in quite-ordinary consumer-level broadcast FM
always
mute the audio between station changes, because “ugly stuff is
happening”. This is exactly the same thing.

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 F. [[email protected]]
Sent: Thursday, January 15, 2015 10:40 AM
To: Anderson, Douglas J.
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

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
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
3582tel:303%20497%203582

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 F. [[email protected]]
Sent: Thursday, January 15, 2015 10:49 AM
To: Anderson, Douglas J.
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
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 F. [[email protected]mailto:[email protected]]
Sent: Thursday, January 15, 2015 10:40 AM
To: Anderson, Douglas J.
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

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
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
3582tel:303%20497%203582

On 01/15/2015 01:11 PM, Anderson, Douglas J. wrote:

acquisitions, almost like a simplified uhd_fft. I would get these

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.

On 01/15/2015 12:55 PM, Anderson, Douglas J. wrote:

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

In that case, you’re probably just looking at DSP artifacts. The DSP
chain doesn’t, as far as I know, run, doing its thing, between
finite_acquistion()
calls. So, it will be in whatever state it was last in, then you
bring it up again, grab some samples, and stop it again. So it doesn’t
really have much
of a chance to achieve steady-state operation with the CIC decimators
and half-band filters. At least, that’s my understanding of what
finite_acquisition() does.

It may be better for you to set-up a streamer to stream continuously,
and then just discard the stuff you don’t want from the stream. Both
the
streaming case.

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
case.

Thanks for the info!
-Doug

of Anderson, Douglas J. [[email protected]]
Sent: Thursday, January 15, 2015 10:55 AM
To: Nick F.
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 F. [[email protected]]
Sent: Thursday, January 15, 2015 10:49 AM
To: Anderson, Douglas J.
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
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 F. [[email protected]mailto:[email protected]]
Sent: Thursday, January 15, 2015 10:40 AM
To: Anderson, Douglas J.
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

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
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
3582tel:303%20497%203582

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
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)
stream_args=uhd.stream_args(‘fc32’))
self.u.set_center_freq(freq)
self.u.set_samp_rate(rate)
self.vsink = blocks.vector_sink_c()

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.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 [[email protected]]
Sent: Thursday, January 15, 2015 11:40 AM
To: Anderson, Douglas J.
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
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:
on behalf of Anderson, Douglas J.
[[email protected]mailto:[email protected]]
Sent: Thursday, January 15, 2015 10:55 AM
To: Nick F.
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 F. [[email protected]mailto:[email protected]]
Sent: Thursday, January 15, 2015 10:49 AM
To: Anderson, Douglas J.
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
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 F. [[email protected]mailto:[email protected]]
Sent: Thursday, January 15, 2015 10:40 AM
To: Anderson, Douglas J.
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

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
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
3582tel:303%20497%203582

[email protected]mailto:[email protected]

Marcus L.
Principal Investigator

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

of Anderson, Douglas J. [[email protected]]
Sent: Thursday, January 15, 2015 11:46 AM
To: Marcus D. Leech
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
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)
stream_args=uhd.stream_args(‘fc32’))
self.u.set_center_freq(freq)
self.u.set_samp_rate(rate)
self.vsink = blocks.vector_sink_c()

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.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 [[email protected]]
Sent: Thursday, January 15, 2015 11:40 AM
To: Anderson, Douglas J.
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
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:
on behalf of Anderson, Douglas J.
[[email protected]mailto:[email protected]]
Sent: Thursday, January 15, 2015 10:55 AM
To: Nick F.
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 F. [[email protected]mailto:[email protected]]
Sent: Thursday, January 15, 2015 10:49 AM
To: Anderson, Douglas J.
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
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 F. [[email protected]mailto:[email protected]]
Sent: Thursday, January 15, 2015 10:40 AM
To: Anderson, Douglas J.
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

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
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
3582tel:303%20497%203582