Underrun occurs when frequency changing

GNU Radio
1

Dear all,

I am trying to transmit a sequence at various frequencies on USRP N200
with LFTX.

When I use the uhd.single_usrp_source.set_center_freq() to change the
frequency then insert the the sequence as a message in the msgq buffer
in another thread other than top_block, underrun occurs. The amplitude
of the transmitting signal on oscilloscope varies some, some of the
signal have the full amplitude that I set, some of them only reach half
amplitude. The following is the thread that I open for the sequence
transmitting.

The mgq are created by:
data=gr.message_source(gr.sizeof_char, msg_limit) #where msg_limit is
defined as 2;
msgq = data.msgq()

transmit_loop(tb)

repeat = 40
payload_13barker = repeat * ‘\x01’
payload_13barker += repeat * ‘\x01’
payload_13barker += repeat * ‘\x01’
payload_13barker += repeat * ‘\x00’
payload_13barker += repeat * ‘\x00’

stop_sign = 5repeat’\x02’
i = 0
while(i<5):
payload_13barker += stop_sign
i += 1

msg_13bit = gr.message_from_string(payload_13barker)
tb._ls.msgq.insert_tail(msg_13bit)
time.sleep(1.0)
print “info inserted”
while 1:
freq_cnt = 4
while (freq_cnt < 7):
i += 1
if i==40: #this counter is used to slow down the rate the transmission
frequency changes
i = 0
tx_freq = freq_cnt * 10e6
tb.set_freq_tx(tx_freq,0.0)
tb._ls.msgq.insert_tail(msg_13bit)
time.sleep(1.0) # suspend to wait for the payload insert into buffer
freq_cnt += 1

I am curious

  1. what causes the underrun and how to avoid the underrun?
  2. How to defined the msgq_limit? Is the underrun cause by the wrongly
    set of the msgq_limit, as I already set to let the program to wait for
    buffering?

Really appreciate any of your suggestion!

Thanks,
Yan

2

On 12/09/2011 03:42 PM, Yan N. wrote:

transmit_loop(tb)
while(i<5):
i += 1
2. How to defined the msgq_limit? Is the underrun cause by the wrongly set of
the msgq_limit, as I already set to let the program to wait for buffering?

Really appreciate any of your suggestion!

Underrun is caused by your flow-graph not being able to provide samples
to the hardware at the specified rate. It looks to me like in
your flow-graph above, your message-queue can easily get starved for
new bits, and so the entire flow-graph stalls. But that’s just
after a superficial inspection. Since you actually go to sleep for
an entire second, it seems like it would be pretty easy for the
flow-graph
to stall.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

3

Really appreciate any of your suggestion!

Underrun is caused by your flow-graph not being able to provide samples to the
hardware at the specified rate. It looks to me like in
your flow-graph above, your message-queue can easily get starved for new bits,
and so the entire flow-graph stalls. But that’s just
after a superficial inspection. Since you actually go to sleep for an entire
second, it seems like it would be pretty easy for the flow-graph
to stall.

Thank you so much for your reply. I am wondering what the reason causes
my message-queue could easily get starved for new bits? How to avoid
this problem with my message-queue? Is the problem of the wrong setting
about the msg_limit for the message-queue? I do not understand how to
set the limit for msgq. What it depends on?

I tried to make the bits loading thread “sleep” for only 0.005s, though
still the underrun occurs. What is the reason of that?

Thanks you so much for any of your suggestions.

Thanks,
Yan

4

On 12/12/2011 01:41 PM, Yan N. wrote:

Thanks you so much for any of your suggestions.

Thanks,
Yan

You need to look at the flow of bits into your flow-graph, and make sure
that flow can keep up with the sample-rate demanded by the
rest of the flow-graph, right up to whatever you’ve programmed the
hardware to do.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium