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

Dennis Zollo dzollo at swift-nav.com
Fri Oct 2 16:09:17 EDT 2015


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.

def async_callback(self, msg):

   print "got a message"


class streamer(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> 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> 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/8907c7a5/attachment-0002.html>


More information about the USRP-users mailing list