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

Dennis Zollo dzollo at swift-nav.com
Wed Oct 14 21:22:29 EDT 2015


Thanks for your help!  Apparently I was crying wolf and the asynch messages
were working all along.

My python script was capturing python's stdout to a file.  However, due to
the nature of SWIG and the internal library calls, I was still getting lots
of output and had forgetting that python's stdout was suppressed.

Best,
Dennis

On Wed, Oct 14, 2015 at 10:15 AM, Martin Braun <martin.braun at ettus.com>
wrote:

> Dennis,
>
> if I run this command:
>
> $ uhd_siggen_gui -s 20e6 --gaussian -c 0,1 --show-async-msg -f 1.982G
>
> ...I'm expecting a lot of underruns, and hence async messages. And sure
> enough, here's the output:
>
> {{{
> ...
> [UHD-SIGGEN] Channel: 0 Time: 4.23692295 Event: 8
> [UHD-SIGGEN] Channel: 0 Time: 4.23697425 Event: 8
> [UHD-SIGGEN] Channel: 1 Time: 4.2370001 Event: 8
> [UHD-SIGGEN] Channel: 0 Time: 4.23702635 Event: 8
> [UHD-SIGGEN] Channel: 1 Time: 4.2370514 Event: 8
> ...
> }}}
>
> Have another look at what's different between the siggen app and yours,
> and maybe you'll find what's up.
>
> Cheers,
> Martin
>
> On 07.10.2015 11:57, Dennis Zollo wrote:
> > 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
> > <mailto: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>
> >     > <mailto: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>
> >     <mailto: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>
> >     <mailto: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/20151014/49d63c4c/attachment-0002.html>


More information about the USRP-users mailing list