[USRP-users] Detect and react to underflow in gnu radio
martin.braun at ettus.com
Wed Oct 14 13:15:15 EDT 2015
if I run this command:
$ uhd_siggen_gui -s 20e6 --gaussian -c 0,1 --show-async-msg -f 1.982G
...I'm expecting a lot of underruns, and hence async messages. And sure
enough, here's the output:
[UHD-SIGGEN] Channel: 0 Time: 4.23692295 Event: 8
[UHD-SIGGEN] Channel: 0 Time: 4.23697425 Event: 8
[UHD-SIGGEN] Channel: 1 Time: 4.2370001 Event: 8
[UHD-SIGGEN] Channel: 0 Time: 4.23702635 Event: 8
[UHD-SIGGEN] Channel: 1 Time: 4.2370514 Event: 8
Have another look at what's different between the siggen app and yours,
and maybe you'll find what's up.
On 07.10.2015 11:57, Dennis Zollo wrote:
> Martin et al,
> I implemented exactly as in this code example, but the asynch callback
> is not called even when the driver prints out 'U' for underflow. Is the
> 'U' supposed to trigger an asychronous message? I think it should be.
> Is there a way I can trigger another asynchronous message to make sure
> the queue and callback are setup correctly?
> On Mon, Oct 5, 2015 at 9:33 AM, Martin Braun <martin.braun at ettus.com
> <mailto:martin.braun at ettus.com>> wrote:
> have a look at the uhd_siggen app in gr-uhd/apps. It has an example on
> how to use the message queue interface.
> On 02.10.2015 13:09, Dennis Zollo wrote:
> > Dear users,
> > Thank you so much for the great feedback!
> > I now have a better code snippet (below) to use the async blocks with a
> > USRP, but my callback is never triggered even. Any advice? I'm still
> > unsure about the first argument to uhd.amsg_source. I've tried it blank
> > and with the a serial="SDFSDF" type string to no avail.
> > defasync_callback(self, msg):
> > print"got a message"
> > classstreamer(gr.top_block):
> > def__init__(
> > ....
> > self.uhd_amsg_source = gr.msg_queue(0)
> > msg = uhd.amsg_source("", msgq=selfuhd_amsg_source)
> > self.async_rcv = gru.msgq_runner(self.uhd_amsg_source, async_callback)
> > Best
> > Dennis
> > On Fri, Oct 2, 2015 at 11:33 AM, Dennis Zollo <dzollo at swift-nav.com <mailto:dzollo at swift-nav.com>
> > <mailto:dzollo at swift-nav.com <mailto:dzollo at swift-nav.com>>> wrote:
> > Martin,
> > Are there any tricks to using the async message block? Does
> > out there have a code snippet? I tried to send the messages to a
> > file sink with the snippet below, but it didn't seem to work. I
> > don't get anything in my file even when see the "U" and "L" in
> > stdout due to underflows. I'm also not sure what the first
> > should be to uhd.amesg_source - I though it would be the
> > string for the device, but now I'm not so sure.
> > uhd_amsg_source = gr.msg_queue(2)
> > msg = uhd.amsg_source("name=MyB210", msgq=uhd_amsg_source)
> > block_msg_src = blocks.message_source(gr.sizeof_gr_complex*1,
> > uhd_am sg_source)
> > msg_sink =
> > blocks.file_sink(gr.sizeof_gr_complex*1, "outfile", False )
> > msg_sink.set_unbuffered(True)
> > self.connect((block_msg_src,0),(msg_sink,0))
> > For some background, I'm getting the underflows when streaming two
> > streams over USB3.0 to each channel of a b210. I have a fast
> > machine and a solid state disk in Raid1. The configuration is
> > for some more background:
> > - bitwise packed files (8 bits per byte)
> > - sample rate of 16368000.0 hz
> > - clock rate of 16368000.0 hz
> > - reading the source file in 16 megabytes chunks
> > - debian with 4.1 kernel
> > - UHD 003.009.000
> > - I get occasional underflows
> > Also, I seem to have fewer underflows when I run with two separate
> > B210s, rather than each channel on the same device. Is this
> > expected behavior, or would I expect two channels on one device to
> > operate more or less the same as two separate cards?
> > Best,
> > Dennis
> > On Fri, Oct 2, 2015 at 9:22 AM, Martin Braun via USRP-users
> > <usrp-users at lists.ettus.com
> <mailto:usrp-users at lists.ettus.com>
> <mailto:usrp-users at lists.ettus.com
> <mailto:usrp-users at lists.ettus.com>>> wrote:
> > On 01.10.2015 15:09, Dennis Zollo via USRP-users wrote:
> > > Hello users,
> > >
> > > I am trying to detect the 'U' and 'L' (underflow & late
> > > messages from transmit on a USRP b210 connected over USB
> 3.0 and
> > > controlled by gnu radio and python. I would merely like
> to know
> > > programmatically that a U or L has occurred and react.
> In our case,
> > > this means we should halt our test and invalidate the
> > >
> > > Does someone have an example of how to do this? Should
> I be using the
> > > asynch message source block? Should I be registering a
> stdout callback
> > > through the C++ api?
> > If you're in GNU Radio, you can use the async message
> block. The
> > only
> > problem is that is uses the legacy message queue model,
> but it's
> > better
> > than parsing output.
> > > Also, what are some strategies to avoid these "late
> packet" or
> > > "underflow" errors and or tune them out of a system?
> > Underflow is hard to avoid (other than beefing up your
> system), late
> > packets can usually be avoided, though. What's causing them in
> > your setup?
> > M
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> <mailto:USRP-users at lists.ettus.com>
> <mailto:USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>>
More information about the USRP-users