Re: Performing a USRP Packet Loopback

[Martin Braun]

Jada,

I haven't read up on all the threads in which you've been asking stuff, so this is lacking a bit of context. I still hope it's helpful:

• I don't think you should downgrade UHD. There has been a lot of change in UHD, but not in the B210 driver.
• UHD provides some tools, such an example called "benchmark_rate", which let you test the streaming rates. Those can be helpful to rule out issues. If you can exchange data in those tools fast enough between USRP and computer (in your case the RPi) then that's a good indicator of things working.
• SMA cables are not strictly necessary, and I think in your particular case they might not provide any benefit. They are generally considered a very useful tool though:
• You don't need to worry about receiving stray RF, or polluting the RF environment in your lab
• They provide a good way of controlling the transmission of RF, meaning you have more influence over how the Rx spectrum will look like. Important: You need attenuators as well as cables, because USRPs are designed to receive tiny levels of RF power, and SMA cables will basically carry the full Tx power.
• This might be old news to new, but you should tune the gain settings of your Tx and Rx before attempting to transmit data. I recommend running an app like uhd_fft on your Rx and see if the spectrum looks "good". If you're clipping or distorting, you'll probably notice in the spectrum, and you'll have no chance of transmitting bits.

--M

On Thu, Jan 21, 2021 at 10:30 PM Jada Mariano Berenguer <berenguj@uci.edu> wrote:

Hi, I think I also forgot to mention that I'm very new at working with GNURadio, the boards, and UHD, so I have some follow up questions. 

Regarding Aditya's reply, why would I need to downgrade the version of UHD? And by 'check it', do you mean run the benchmark, transmitting, and receiving examples to see if there's overruns or underruns? Also, what benefit does attaching SMA cables before attaching antennas have? Because I don't have any SMA cables, but if there's some significant benefit I'll look into getting some. 

Regarding Marcus's reply, I've attached a picture of the flowgraph for the packet-tx block so we can determine if it uses start-of-burst/end-of-burst tagging, because I'm not sure how to tell. I think it uses start-of-burst tagging because of the PDU to Tagged Stream blocks at the beginning of the flowgraph but am unsure. Also, if it is the case that it doesn't use start-of-burst/end-of-burst tagging, I found a property of the packet_tx and packet_rx blocks called 'Maxoutbuf'. Could I use these properties to set a buffering policy? And what size buffer would I need?

Again, what I'm trying to do is follow what was said in this message thread. It says that the packet_loopback example is a transceiver, and I can replace the Channel Model blocks with USRP source and USRP sink blocks to try to send a message over the air. I did that, but I'm running into overruns and underrruns and want to know how to fix that. 

Thanks everybody for speedy replies and the help so far! It's much appreciated!!

On Wed, Jan 20, 2021 at 9:11 AM Marcus D. Leech <patchvonbraun@gmail.com> wrote:

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.