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

Martin Braun martin.braun at ettus.com
Wed Oct 14 13:15:15 EDT 2015


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





More information about the USRP-users mailing list