[USRP-users] Detect and react to underflow in gnu radio
dzollo at swift-nav.com
Fri Oct 2 16:09:17 EDT 2015
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"
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)
On Fri, Oct 2, 2015 at 11:33 AM, Dennis Zollo <dzollo at swift-nav.com> wrote:
> 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
> msg_sink = blocks.file_sink(gr.sizeof_gr_complex*1, "outfile", False )
> 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?
> 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?
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users