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

**URL:** <https://www.ruby-forum.com/t/usrp-transient-peak-from-lock-unlock-set-decim-freq/209347>\
**Category:** GNU Radio\
**Created:** [July 12, 2011, 11:18am UTC](https://www.ruby-forum.com/t/usrp-transient-peak-from-lock-unlock-set-decim-freq/209347 "2011-07-12T11:18:43Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\
**Post date:** [July 12, 2011, 11:18am UTC](https://www.ruby-forum.com/t/usrp-transient-peak-from-lock-unlock-set-decim-freq/209347/1 "2011-07-12T11:18:43Z")

</div>

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’

---

<div class="post-metadata">

**Author:** ![jst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/edb3f5/32.png) [@jst](https://www.ruby-forum.com/u/jst)\
**Post date:** [July 12, 2011, 8:22pm UTC](https://www.ruby-forum.com/t/usrp-transient-peak-from-lock-unlock-set-decim-freq/209347/2 "2011-07-12T20:22:35Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/edb3f5/32.png) [@jst](https://www.ruby-forum.com/u/jst)\
**Post date:** [July 12, 2011, 8:58pm UTC](https://www.ruby-forum.com/t/usrp-transient-peak-from-lock-unlock-set-decim-freq/209347/3 "2011-07-12T20:58:25Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![jst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/edb3f5/32.png) [@jst](https://www.ruby-forum.com/u/jst)\
**Post date:** [July 19, 2011, 2:52pm UTC](https://www.ruby-forum.com/t/usrp-transient-peak-from-lock-unlock-set-decim-freq/209347/4 "2011-07-19T14:52:30Z")

</div>

> 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