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

Dennis Zollo dzollo at swift-nav.com
Fri Oct 2 14:33:19 EDT 2015


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> 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
> 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/20151002/92608a4a/attachment-0002.html>


More information about the USRP-users mailing list