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

Martin Braun martin.braun at ettus.com
Mon Oct 5 12:33:02 EDT 2015


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
> 
> 
> 





More information about the USRP-users mailing list