# Voltage pulse from UHD driver **URL:** \ **Category:** GNU Radio\ **Created:** [January 15, 2015, 6:27pm UTC](https://www.ruby-forum.com/t/voltage-pulse-from-uhd-driver/233835 "2015-01-15T18:27:43Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [January 15, 2015, 6:27pm UTC](https://www.ruby-forum.com/t/voltage-pulse-from-uhd-driver/233835/1 "2015-01-15T18:27:43Z")
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: > 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:](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 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 15, 2015, 6:40pm UTC](https://www.ruby-forum.com/t/voltage-pulse-from-uhd-driver/233835/2 "2015-01-15T18:40:38Z")
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. ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 15, 2015, 6:41pm UTC](https://www.ruby-forum.com/t/voltage-pulse-from-uhd-driver/233835/3 "2015-01-15T18:41:52Z")
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. \< ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 15, 2015, 6:51pm UTC](https://www.ruby-forum.com/t/voltage-pulse-from-uhd-driver/233835/4 "2015-01-15T18:51:07Z")
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. \< ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 15, 2015, 6:52pm UTC](https://www.ruby-forum.com/t/voltage-pulse-from-uhd-driver/233835/5 "2015-01-15T18:52:58Z")
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 receivers, for example. The digitally-tuned PLL receivers will almost _always_ mute the audio between station changes, because “ugly stuff is happening”. This is exactly the same thing. ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 15, 2015, 6:47pm UTC](https://www.ruby-forum.com/t/voltage-pulse-from-uhd-driver/233835/6 "2015-01-15T18:47:24Z")
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. [removed\_email\_address@domain.invalid] Sent: Thursday, January 15, 2015 10:40 AM To: Anderson, Douglas J. Cc: GNURadio D.ion 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. \ 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: > 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:](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 3582tel:303%20497%203582 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 15, 2015, 6:56pm UTC](https://www.ruby-forum.com/t/voltage-pulse-from-uhd-driver/233835/7 "2015-01-15T18:56:39Z")
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. [removed\_email\_address@domain.invalid] Sent: Thursday, January 15, 2015 10:49 AM To: Anderson, Douglas J. Cc: GNURadio D.ion 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. \ 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. [removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Thursday, January 15, 2015 10:40 AM To: Anderson, Douglas J. Cc: GNURadio D.ion 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. \ 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: > 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:](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 3582tel:303%20497%203582 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 15, 2015, 7:42pm UTC](https://www.ruby-forum.com/t/voltage-pulse-from-uhd-driver/233835/8 "2015-01-15T19:42:12Z")
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. ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 15, 2015, 7:07pm UTC](https://www.ruby-forum.com/t/voltage-pulse-from-uhd-driver/233835/9 "2015-01-15T19:07:05Z")
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 hardware, and Gnu Radio are really optimized for the steady-state streaming case. ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 15, 2015, 7:13pm UTC](https://www.ruby-forum.com/t/voltage-pulse-from-uhd-driver/233835/10 "2015-01-15T19:13:15Z")
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 * * * From: discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid] on behalf of Anderson, Douglas J. [removed\_email\_address@domain.invalid] Sent: Thursday, January 15, 2015 10:55 AM To: Nick F. Cc: GNURadio D.ion 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 F. [removed\_email\_address@domain.invalid] Sent: Thursday, January 15, 2015 10:49 AM To: Anderson, Douglas J. Cc: GNURadio D.ion 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. \ 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. [removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Thursday, January 15, 2015 10:40 AM To: Anderson, Douglas J. Cc: GNURadio D.ion 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. \ 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: > 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:](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 3582tel:303%20497%203582 ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 15, 2015, 7:48pm UTC](https://www.ruby-forum.com/t/voltage-pulse-from-uhd-driver/233835/11 "2015-01-15T19:48:22Z")
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](http://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 [removed\_email\_address@domain.invalid] Sent: Thursday, January 15, 2015 11:40 AM To: Anderson, Douglas J. Cc: GNURadio D.ion 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: discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid[mailto:discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid) [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid[mailto:discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid)] on behalf of Anderson, Douglas J. [removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Thursday, January 15, 2015 10:55 AM To: Nick F. Cc: GNURadio D.ion 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 F. [removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Thursday, January 15, 2015 10:49 AM To: Anderson, Douglas J. Cc: GNURadio D.ion 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. \ 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. [removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Thursday, January 15, 2015 10:40 AM To: Anderson, Douglas J. Cc: GNURadio D.ion 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. \ 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: > 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:](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 3582tel:303%20497%203582 * * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) – Marcus L. Principal Investigator Shirleys Bay Radio Astronomy Consortium > **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org/)** > > Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami. ---
**Author:** ![AndersonS\_Douglas\_J](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/53a042/32.png) [@AndersonS\_Douglas\_J](https://www.ruby-forum.com/u/AndersonS_Douglas_J)\ **Post date:** [January 15, 2015, 8:01pm UTC](https://www.ruby-forum.com/t/voltage-pulse-from-uhd-driver/233835/12 "2015-01-15T20:01:19Z")
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: discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid] on behalf of Anderson, Douglas J. [removed\_email\_address@domain.invalid] Sent: Thursday, January 15, 2015 11:46 AM To: Marcus D. Leech Cc: GNURadio D.ion 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](http://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 [removed\_email\_address@domain.invalid] Sent: Thursday, January 15, 2015 11:40 AM To: Anderson, Douglas J. Cc: GNURadio D.ion 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: discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid[mailto:discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid) [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid[mailto:discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid)] on behalf of Anderson, Douglas J. [removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Thursday, January 15, 2015 10:55 AM To: Nick F. Cc: GNURadio D.ion 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 F. [removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Thursday, January 15, 2015 10:49 AM To: Anderson, Douglas J. Cc: GNURadio D.ion 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. \ 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. [removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] Sent: Thursday, January 15, 2015 10:40 AM To: Anderson, Douglas J. Cc: GNURadio D.ion 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. \ 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: > 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:](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 3582tel:303%20497%203582 * * * Discuss-gnuradio mailing list removed\_email\_address@domain.invalid[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) – Marcus L. Principal Investigator Shirleys Bay Radio Astronomy Consortium > **[Live Draw HK Tercepat | Result HK | HK Pools | Live HK | HK Prize Hari Ini](https://www.sbrac.org/)** > > Temukan live draw hk tercepat melalui halaman hk pools yang resmi dan dapatkan result hk prize melalui live hk secara langsung di situs kami.