[USRP-users] Detect and react to underflow in gnu radio

Dennis Zollo dzollo at swift-nav.com
Wed Oct 7 14:57:27 EDT 2015


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?

Best,
Dennis




On Mon, Oct 5, 2015 at 9:33 AM, Martin Braun <martin.braun at ettus.com> wrote:

> Dennis,
>
> have a look at the uhd_siggen app in gr-uhd/apps. It has an example on
> how to use the message queue interface.
>
> Cheers,
> Martin
>
> 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>> wrote:
> >
> >     Martin,
> >
> >     Are there any tricks to using the async message block?  Does anyone
> >     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 argument
> >     should be to uhd.amesg_source - I though it would be the identifying
> >     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 below
> >     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>>
> 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
> packet)
> >         > 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 results.
> >         >
> >         > 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>
> >
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151007/673b86a2/attachment-0002.html>


More information about the USRP-users mailing list