Hello,
I’ve been working with Gnu Radio on a pair of two USRP2’s for a couple
of months and have been very impressed with what they can do but have
gotten stuck by a series of occasional underruns which I can seem to
trace the source of.
Specifically, I have the USRP2’s direct connected driven by an external
reference source. I noticed on the receiver I occasionally was missing
samples from what I thought was sent on the transmitter. Running the
code just in software (aka, removing the USRP2 source and sink blocks)
ran just fine which made me strongly suspect how samples were
sent/received to the USRP2’s.
After much debugging, I’ve found that if I observe the debug UART on the
transmitter I can see a ‘U’ via a serial console whenever I have missing
samples on the receiver. I’ve been removing blocks from my transmitter
to try and trace the source of what causes the underruns but haven’t had
alot of luck. I generally get a ‘U’ anywhere from 9-15 minutes but
addition of a block which does nothing but copy the input to the output
causes this to drop to 1-3 minutes. Forcing “set_output_multiple” to a
large number such as 1000 increases the time before I see a ‘U’ but
doesn’t completely prevent it and I can’t figure out why it would cause
a problem at all.
Anyone have any ideas of why I’m seeing very occasional underruns? From
what I’ve read I thought that leaving “set_output_multiple” out and
letting the scheduler decide how many it needs would be the most
efficient but it looks to not be the case.
My hardware setup is as follows:
USRP2 with a 10MHz reference running with a interpolation of 10
6 core 3.3GHz Xeon (Processor usage is very low) with RTS enabled
If anyone has any ideas as to why or a good way to debug please let me
know.
Thanks,
James Streitman
So, I’ve narrowed down what the problem is a bit from the last post but
I’m almost completely stumped as to what’s actually causing it.
I created a couple of “do nothing” blocks that simply copy their input
to their output. I still however see underruns periodically on the
USRP2. I’ve removed all other custom blocks such that my flowgraph
consists of a random byte source, a byte to float type-converter, a
float to complex converter, a series of do_nothing blocks and a USRP2
sink.
I tried inheriting from gr_block and from gr_sync_block but got the same
results: A very slow (sometimes minutes inbetween each) stream of ‘U’
over the UART to the USRP2. I found that if I increase “set_output_rate”
from the default value to 500 it seems to decrease the number of
underruns. Printing the actual values of “noutput_items” from each
function call shows either 4000 or 4096 with set_output_rate(500) or the
default value.
Can someone else reproduce this problem? It seems as though it’s in Gnu
Radio itself or on the USRP2.
Thanks,
James
James Streitman wrote:
Hello,
I’ve been working with Gnu Radio on a pair of two USRP2’s for a couple
of months and have been very impressed with what they can do but have
gotten stuck by a series of occasional underruns which I can seem to
trace the source of.
Specifically, I have the USRP2’s direct connected driven by an external
reference source. I noticed on the receiver I occasionally was missing
samples from what I thought was sent on the transmitter. Running the
code just in software (aka, removing the USRP2 source and sink blocks)
ran just fine which made me strongly suspect how samples were
sent/received to the USRP2’s.
After much debugging, I’ve found that if I observe the debug UART on the
transmitter I can see a ‘U’ via a serial console whenever I have missing
samples on the receiver. I’ve been removing blocks from my transmitter
to try and trace the source of what causes the underruns but haven’t had
alot of luck. I generally get a ‘U’ anywhere from 9-15 minutes but
addition of a block which does nothing but copy the input to the output
causes this to drop to 1-3 minutes. Forcing “set_output_multiple” to a
large number such as 1000 increases the time before I see a ‘U’ but
doesn’t completely prevent it and I can’t figure out why it would cause
a problem at all.
Anyone have any ideas of why I’m seeing very occasional underruns? From
what I’ve read I thought that leaving “set_output_multiple” out and
letting the scheduler decide how many it needs would be the most
efficient but it looks to not be the case.
My hardware setup is as follows:
USRP2 with a 10MHz reference running with a interpolation of 10
6 core 3.3GHz Xeon (Processor usage is very low) with RTS enabled
If anyone has any ideas as to why or a good way to debug please let me
know.
Thanks,
James Streitman