USRP transient peak from lock, unlock, set decim/freq

GNU Radio
1

I am getting some kind of very strong transient peak when using lock
unlock and changing usrp decimation rate and frequency and in the
beginning.
Is this a normal behaviour?
So each time I reconfigure my system I have to throw away some samples
to avoid this peak or am I doing something wrong?

I made this short example program and the peak can be found at the
beginning of the logged data and somewhere in the middle. The
beginning peak only occurs sometimes. So make sure to run it several
times if you want to see it.
It happens in USRP1 as well as USRP2.

I hope somebody can confirm this or tell me that the problem has been
removed in newer gnuradio versions.

Johannes

#!/usr/bin/env python

from gnuradio import gr
from gnuradio import usrp
from gnuradio import usrp2
from gr_tools import log_to_file

from time import sleep

class top_block(gr.top_block):
def init(self):
gr.top_block.init(self, “fusb error”)

    self.u = usrp.source_c ()

self.u = usrp2.source_32fc(‘eth1’)

    self.sink = gr.null_sink(gr.sizeof_gr_complex)
    self.connect(self.u, self.sink)

    log_to_file(self, self.u, "data/test_u.compl")

def reconfigure(self):
    self.lock()
    sleep(1)
    print 'lock'
    self.unlock()
    print 'unlock'

if name == ‘main’:
app = top_block()
app.start()
sleep(1)
print ‘start’
app.reconfigure()
print “reconfigured”
sleep(1)
print ‘now stopping’
app.stop()
print ‘stopped’

2

On Tue, 2011-07-12 at 11:07 +0200, Johannes S. wrote:

I am getting some kind of very strong transient peak when using lock
unlock and changing usrp decimation rate and frequency and in the
beginning.
Is this a normal behaviour?
So each time I reconfigure my system I have to throw away some samples
to avoid this peak or am I doing something wrong?

This is normal behavior. Each time the daughterboard is re-tuned, there
is a transient as the VCO settles. A smaller (and much shorter)
transient is expected during rate changes as well due to different
filters being switched in and out. It’s best to throw away the first few
samples after changing frequency or rate.

–n

3

On 12/07/2011 1:05 PM, Nick F. wrote:

filters being switched in and out. It’s best to throw away the first few
samples after changing frequency or rate.

–n
Also, there’s no reason to lock the flow-graph for frequency changes or
gain changes (or a bunch of other parametric changes
within the flow-graph). I’ve never had to use lock()/unlock()–I
understand that they’re used during flow-graph topology changes.
But parametric changes don’t require lock()/unlock() at all.

Most modern digital consumer-appliance tuners tend to mute the audio
during re-tune, precisely because PLL settling takes a finite time,
and typically produces glitches.

Any real communications system will necessarily have to “cope” with
glitches on the channel. Very few RF channels are completely clean
and free of RFI and other artifacts of nature…

4

Also, there’s no reason to lock the flow-graph for frequency changes or gain
changes (or a bunch of other parametric changes
within the flow-graph). I’ve never had to use lock()/unlock()–I
understand that they’re used during flow-graph topology changes.
But parametric changes don’t require lock()/unlock() at all.
Actually I am using lock and unlock for flowgraph reconfiguration
during runtime.

I found a way how to avoid transient problems. I will just reset my
filters some time after it occurs.

Now I found another similar problem. I saw this somewhere before but
forgot that it occurs:
When I stop my receiver and transmitter and then look at usrp_fft I
can still see a very strong and small peak at the carrier frequency.
How can I avoid/remove this?

Regards,
Johannes