[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] voltage pulse from UHD driver
Date: Thu, 15 Jan 2015 13:05:21 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 01/15/2015 12:55 PM, Anderson, Douglas J. wrote:
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!


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.

From: Nick Foster [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.


On Thu, Jan 15, 2015 at 9:46 AM, Anderson, Douglas J. <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?


From: Nick Foster [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.


On Thu, Jan 15, 2015 at 9:26 AM, Anderson, Douglas J. <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. 

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

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

def plot():
    data = "">
    shifted_fft = np.fft.fftshift(np.fft.fft(data))
    dBm = 20*np.log10(np.abs(shifted_fft)) - 30

def run_tb(times=25):
    for _ in range(times):

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

Discuss-gnuradio mailing list

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]