Re: Performing a USRP Packet Loopback

[Marcus D. Leech]

On 01/20/2021 12:12 AM, Jada Mariano Berenguer wrote:
> Hi, I realized that in my packet loopback example, I didn't connect 
> any of the QT GUI sinks after the USRP source. The updated flow graph 
> is attached in screenshot0. After I connected them, I ran the packet 
> loopback example on my MacBook Air using one B210 board with TX/RX and 
> RX2 antennas attached and got the results attached in screenshot1, but 
> still received underruns as printed out in the terminal in the bottom 
> left corner. I also ran the example with two B210 boards with a TX/RX 
> antenna on one and a RX2 antenna on the other and got slightly 
> different results. Instead, the third graph was just a straight 
> horizontal line and still ran into underruns. I also ran the same 
> program with a Raspberry Pi 4 with one B210 board and got 
> similar results. So I don't think it's an issue concerning computer 
> power.
>
> Also, I was wondering what you meant by "for a loopback flow at low 
> rates you may need to alter the internal buffer sizes in your 
> flow-graph to prevent TX starving for samples because the RX buffers 
> are still filling. But this is not a distinctly USRP problem and has 
> more to do with GnuRadio". How would I alter the internal buffer sizes 
> and what would I need to change it to?
>
> Are there any other suggestions you have for me to successfully get 
> this loopback example running?
>
> Thanks!
My comments on buffer sizes were driven by an incomplete understanding 
of what you were doing--however, having said that,
  at low sample rates, the default buffer sizes used by Gnu Radio may 
become an issue.

See the Options block to set a global buffering policy:

https://wiki.gnuradio.org/index.php/Options

I'm not that familiar with the blocks you're using in your flow-graph.   
If the packet-tx block doesn't use start-of-burst/end-of-burst tagging,
  the the UHD sink block will underrun between bursts, since it will be 
expecting a continuous flow, but only receiving a bursty flow. This may
  not be a problem here--I just don't know how that packet-tx block works.